Zapier, Claude or ChatGPT · Practical walkthrough

Set the actions an AI agent must stop for

The agent can draft, send, refund and update records. Decide which actions need a person before switching it on.

Task by Task8 min read

What you'll make

a stop list for one agent or AI workflow: the actions it must not finish alone, the setting that enforces each one, who approves, and what happens if nobody does.

What you'll need

the agent’s list of connected tools and permissions, admin access to its settings (or the person who has it), the names of the people who’d approve, and about forty minutes. For this guide, an agent is anything that can act in another system without a person pressing the button for that action.

Example result.

1. Send any message outside our domain.
   Control: Zapier Request Approval before send. Decline: Stop run. On timeout: End run.
   Approver: duty customer care lead (named rota).
2. Issue a refund or credit of any value.
   Control: refund action unavailable to the agent; a person reviews it in the order system.

1. Ask for gaps in one action list

List concrete actions, such as searching orders, sending replies and issuing refunds. Note the destination and consequence of each, without customer data or credentials. Paste that list and your policy into your work chat:

Review this list of agent actions using only the details I've given. Find missing destinations, unclear approvers, permissions broader than the task needs, actions that could repeat, and actions with no safe outcome when information is missing. For each issue, draft a stop-list line with the exact action, approver, the setting that would enforce it, what happens on decline or timeout, and a test with its expected result. Keep my existing policy separate from your suggestions. Don't judge legal compliance.

Actions and policy:
[your action records]

[your action records] means the action list and the policy that applies.

Why this works: a tool list exposes risky steps that a friendly description such as “manage customers” can hide.

What you should see: proposed stop points with unresolved controls clearly marked.

2. Review the proposal before changing settings

For each action, ask whether money moves, a person outside the team sees it, or information is deleted or overwritten. Check reversibility and any legal or contractual deadline. A serious consequence needs an explicit decision from the owner; do not add scores together to wave it through.

Why this works: AI can notice a blank approver field, but it cannot establish that a suggested setting exists in your account.

What you should see: each stop point has an action, target, approver and a safe outcome for decline or no response.

3. Attach a setting that actually stops the action

Give the agent the narrowest access the job needs. If it only reads order status, it doesn’t need a refund tool. Then set each stop-list line in the product:

Claude connectors (Team and Enterprise owners): in Customize › Connectors, select the connector and open Tool permissions. Set each category or tool to Always allow, Needs approval or Blocked, for example allowing email search but blocking send. The setting applies to everyone using the connector.
ChatGPT apps: app permissions offer Always ask, Allow read actions, Allow low-risk actions and, for some individual apps, Allow all actions. Labels and availability vary by account and app. Allow all actions, where offered, can let supported actions run without another prompt; it does not override provider access, workspace rules or safety restrictions. Don’t use it for anything on your list.
Zapier (paid plan): create an owned pending record before the approval, then add Human in the Loop › Request Approval before the action. Set Action if reviewer declines to Stop run and On timeout to End run.

Why this works: a setting is enforced by the product. “Ask first” in the agent’s instructions is only a request, and Claude and ChatGPT settings can only narrow access the account already has.

What you should see: every “needs approval” or “not available” line matched to a named setting you’ve seen with your own eyes.

4. Check the settings that quietly undo it

These look fine in a workshop and fail on a Friday:

Timeout. With On timeout set to Skip and continue, the step delays the action rather than requiring approval. For this stop list, choose End run.
Who can approve. Reviewers need a Zapier account and the Zap shared with them. On a Professional account, reviewer options are restricted; check which reviewer types your account offers before designing the rota. On Team or Enterprise, the reviewer must be logged in as one of the users you selected.
What happens on decline. Stop run prevents later steps from running. Create the pending item and assign its owner before requesting approval, so a stopped or unanswered run remains visible for manual follow-up. Test any separate notification route on its own.
Error handling. Zapier sends no error notification emails when a custom error handler runs, and publishing a Zap with one turns autoreplay off for that Zap. Add your own alert inside the handler.

Then test with fictional records and a harmless destination: approved, declined, no response, and an order that can’t be matched. The editor’s step test doesn’t notify reviewers, so run the Zap end to end and check the destination afterwards.

Why this works: most failed controls are set up correctly except for one default that lets the run continue.

What you should see: four test outcomes, each matching the expected result on your stop list.

Check the result

Every irreversible or external action has a named setting, not just an instruction.
Every approval step has decline set to stop and timeout set to end the run.
Every approver can actually receive and complete the request.
Declined and unanswered items land in a queue someone owns.

The usual failure: the stop list says “needs approval”, but the timeout says Skip and continue. When nobody responds, the action goes ahead anyway. You’ll only see it by testing the no-response case end to end and checking the destination.

This test failed: [what happened]. The stop list required [expected outcome]. Using the settings I've described, identify which setting doesn't cover this path and what I should change. Don't suggest removing the approval step or widening permissions.

Settings:
[the step's settings]

[what happened] is the observed result, [expected outcome] the line from your stop list, and [the step's settings] the decline, timeout and reviewer settings as shown in the editor.

Worked example: the £30 refund and the four-hour wait

Fictional example. A homeware retailer’s agent reads the enquiries inbox, looks up orders, drafts replies and can issue refunds up to £30 under the returns policy. The first stop list said:

Send external reply: Request Approval. Decline: Stop run. On timeout: Skip and continue (4 hours).
Refund under £30: may finish alone (within policy).
Unmatched order: draft a reply anyway.

The no-response test sent a reply to the fictional customer four hours after the request. The repair prompt pointed to On timeout. The revised list:

1. Send any message outside our domain.
   Control: create an owned pending item in the care queue first; then Request Approval. Decline: Stop run.
   On timeout: End run. Approver: duty customer care lead (named rota).
2. Issue a refund, credit or goodwill payment of any value.
   Control: refund action unavailable to the agent; the care lead handles it separately.
3. Delete or overwrite an order, address or contact detail.
   Control: write and delete tools Blocked on that connector.
4. Complaint, legal or safety wording.
   Control: routed to the care queue; agent does not draft.
5. Order can't be matched with confidence.
   Control: agent writes NOT MATCHED to the queue and stops.
Review: 6 January 2027, or sooner if approvals are granted without exception for four weeks running.

The timeout. Changing one setting turned a delay into a stop. The retest left the reply unsent and the item in the queue.
The £30 line. The threshold is a sensible policy, and a person applying it is fine. But a threshold is a policy control, and the stop list is a safety control. A refund moves money and may not be reversible; this team’s stop list therefore requires approval. If volume makes that impractical, batch them for one approval.
NOT MATCHED. An agent that can’t match an order produces a reply as confident as any other. Writing NOT MATCHED and stopping turns an invisible error into a visible one.

Go deeper

Optional training: Keep approvals from becoming a click

If an approval arrives twenty times a day and is always approved, it’s become a rubber stamp. Two lines that genuinely stop things are worth more than eight that produce a stream of approvals. Name people or a staffed rota with a backup, give reviewers the evidence and the authority to reject, and watch the queue size. A run of approvals with no exceptions is a finding: either the line isn’t needed, or nobody is really reviewing. Use the review trigger in the worked example to make someone look.

Optional training: Cover other routes to the same action

Blocking the send tool on one connector doesn’t help if another connected app, a shared account or a browser tool can send the same message. Review every connection the agent has, together, and ask who can change the settings and how that change is recorded. For what a customer-facing bot may say, as opposed to do, see What support AI must never answer.

Optional training: Get specialist advice for decisions about people

Decisions about employment, lending, healthcare and similar matters need legal, privacy and professional review for your jurisdiction. In the UK, the ICO’s guidance on automated decision-making is the starting point, and the law in this area has been changing. Put the specific decision to your data protection officer in writing. An approval button doesn’t by itself make human involvement meaningful.