AI Automations with Zapier, Make, and n8n
Add model steps to automated workflows: triggers, AI actions, structured output, error paths, and human approval before anything important happens.
Automation platforms have connected apps for years: when a form is submitted, add a row; when a deal closes, post in a channel. What they couldn't do was handle messy input. An email that says "the mug arrived in pieces, order 4471, can I get my money back?" defeated every filter rule you could write. A model step changes that. It reads the mess and turns it into clean fields that the rest of the workflow can act on.
That power is also the risk. An automation runs without anyone watching, hundreds of times, and a model step will occasionally be confidently wrong. In this lesson you'll build a refund-request workflow that uses the model only for the messy part, gets structured output, handles errors on purpose, and waits for a human before any money moves. The pattern works in Zapier, Make, and n8n.
The anatomy of an AI automation
Every automation in these platforms is a chain of steps. Zapier calls the chain a Zap, Make calls it a scenario made of modules, and n8n calls it a workflow made of nodes. The parts are the same:
- Trigger: the event that starts a run. A new email, a form submission, a new row, a schedule.
- Filter: a cheap, rule-based check that stops runs you don't care about before they cost anything.
- AI step: a model call that turns messy input into structured fields.
- Checks: ordinary rule-based steps that validate what the model returned against your real data.
- Routing: branches that send different cases down different paths.
- Human approval: a pause where a person approves, edits, or rejects before anything consequential happens.
- Action: the step that changes the world: sends the reply, issues the refund, updates the record.
- Error path: what happens when any step fails.
Most beginner automations have steps 1, 3, and 7 only: trigger, AI, action. That's the version that emails a customer something strange at 3 a.m. The other five steps are what make it safe to leave running.
Here's the workflow you'll build, for a small online store's support inbox:
| Step | What it does | Model involved? |
|---|---|---|
| Trigger | New email arrives at the support address | No |
| Filter | Skip newsletters, auto-replies, and internal senders | No |
| AI step | Is this a refund request? Extract order number, reason, and a summary | Yes |
| Check | Look up the order: does it exist, and does the sender's email match? | No |
| Route | Clear, small, verified requests → standard approval; everything else → manager | No |
| Approval | Post the summary and a drafted reply in the team chat; wait for a decision | No |
| Action | On approval, issue the refund and send the reply | No |
| Error path | Any failure → alert the team with a link to the run | No |
Notice how small the model's job is. It reads one email and fills in a few fields. Everything that touches money or customers is ordinary, predictable logic. That's the right division of labor: models for judgment on messy text, rules for everything you can write a rule for.