Learning Objectives
- Understand the difference between scheduled and event-driven automation
- Recognise where event-driven hooks solve real business problems
- Design an automation chain you could hand to Claude or IT to implement
🎯 What You'll Learn: When event-driven automation is more powerful than scheduling, and how to design a chain that runs itself
⏱️ Time Required: 20 minutes
Scheduled vs Event-Driven
You now understand scheduled automation: Claude runs something at a fixed time, every time.
Event-driven automation is different. Instead of "run at 8am Monday", the trigger is "run whenever this happens."
| Scheduled | Event-driven | |
|---|---|---|
| Trigger | A time | An action or event |
| Best for | Recurring tasks you can predict | Reactions to things that happen |
| Example | Weekly report every Monday | Log every file Claude writes |
Both have their place. In a real workflow, you'll use both.
Riley's New Challenge
Riley's margin report runs automatically every Monday. But she has a new problem:
"When Claude edits a data file during a session, I have no record of what changed. My compliance team wants to know: what files did Claude touch, when, and in which session? And I want the margin report to automatically trigger a validation step when it finishes, not just produce a file and stop."
— Riley Harper
This is where event-driven hooks come in.
Three Patterns That Solve Real Problems
Pattern 1: The Audit Log
The business problem: You need a record of what Claude changed and when, for compliance, review, or peace of mind.
How it works: Every time Claude writes a file, a PostToolUse hook logs the file name, timestamp, and session ID. You end up with a complete audit trail without anyone maintaining it manually.
What it looks like from the outside:
Claude finishes a session
↓
You open your log file
↓
Every file Claude touched is listed with timestamps
↓
Compliance team has the evidence they need
Who needs this: Anyone in a regulated environment, handling client data, or working with systems that require accountability over automated actions.
Pattern 2: The Automation Chain
The business problem: You want Task B to happen automatically when Task A finishes, without anyone triggering it.
How it works: A Stop hook fires when Claude's session ends. It triggers the next task automatically, a validation run, a notification, another Claude session, anything you need.
Riley's chain:
margin report finishes
↓ (Stop hook fires)
Validation runs automatically
↓
Slack notification sent
↓
Riley gets the message on her phone
What it looks like from the outside: The report runs at 7:30am. By 7:45am Riley gets a Slack message: "Margin report complete. Validation: PASS." She didn't touch anything between those two events.
Who needs this: Anyone who currently has to manually trigger Step 2 after Step 1 finishes, or who forgets to.
Pattern 3: The Safety Check
The business problem: Before Claude touches something important, you want a guardrail that happens automatically, not one you have to remember to apply.
How it works: A PreToolUse hook fires before Claude acts. It can log what's about to happen, verify conditions, or stop the action entirely if something doesn't look right.
Examples:
Who needs this: Anyone giving Claude access to important systems who wants an extra layer of visibility and control before anything irreversible happens.
Designing Your Event-Driven Automation
All three patterns follow the same logic:
Exercise: Map Your Automation Chain
⏱️ Total Time: 20 minutes
Step 1: Pick the pattern that fits your work (5 min)
Step 2: Map it out in plain English (15 min)
Event: [What triggers this — e.g. "Claude finishes writing a file" / "Claude session ends"]
Response: [What should happen automatically]
Output: [Where does the result go — log file, Slack, next task?]
Why: [What problem does this solve for you?]
Riley's audit log:
Event: Claude writes any file during a session
Response: Log the file name, timestamp, and session ID
Output: ~/audit/claude-changes.log
Why: Compliance requirement — need a full record of what changed
Riley's automation chain:
Event: Claude session ends after running the margin report
Response: Trigger a validation task, then send a Slack notification
Output: Slack message — "Margin report complete. Validation: PASS/FAIL"
Why: I want to know it finished correctly without checking manually
Yours:
Event: _______________
Response: _______________
Output: _______________
Why: _______________
💡 To implement it: Take your completed template to Claude Code and say: "I want to set up an event-driven hook. Here's what I need: [paste your template]. Can you configure this in my settings?"
Claude writes the configuration. Your job is to read it back, confirm it matches your intent, and test that the output appears where you expected.
✅ Success Criteria:
Ready to Build It Yourself?
This course teaches you to recognise hook opportunities and describe them clearly. If you want to go further into the technical implementation, shell commands, JSON configuration, programmatic automation, Anthropic Academy has free courses that cover that ground.
What Riley Built
"I now have three things that didn't exist three weeks ago: an audit log that satisfies my compliance team, a validation step that runs automatically after every report, and a Slack message that tells me when it's all done. I described what I needed. Claude set it up. That's the whole point."
Next Up
Lesson 3.4: Introduction to MCP
Your automations run on schedule and respond to events. Now you'll connect Claude to the tools your business actually uses, calendars, CRMs, databases, and more, via Model Context Protocol.