How to Set Up Per-Tool Approval in a Zapier AI Step

Introduction

An AI step that can read your price list is useful. An AI step that can email your customers, update your CRM, and delete records without anyone checking first is a liability. In Zapier, the difference is one toggle, set separately on each tool inside the AI by Zapier step. This tutorial shows you how to set it up so sensitive actions wait for a human while harmless reads keep running, and how to cap a looping agent before it spends your task budget.

Quick answer

In the AI by Zapier step, turn on Require approval before running on tools that send, charge, update, or delete, and leave read-only tools ungated.

Evidence

The feature exists because the old model was too coarse. Zapier’s announcement for AI by Zapier states that where the old Agents product was all-or-nothing on approval, the AI step lets you set approval granularity per action. Zapier’s help documentation states the rule to build around, and it is worth quoting exactly because it is also the most common mistake in this setup:

“Turn on Require approval before running for sensitive actions, such as tools that create, update, or delete data. Leave it off for low-risk actions, such as reads, so your Zap runs without unnecessary pauses.”

Note the default: the same help page states the toggle is off by default, so a tool runs without interruption unless you turn it on. Most approval failures trace back to assuming a tool was gated when it was not.

Two numbers set the stakes. First, the runaway brake: Zapier’s migration guide for Agents to AI by Zapier states that a single run exceeding its task limit, 75 tasks by default and adjustable up to 500, automatically pauses for review before continuing. Second, the trust gap: in a Zapier survey of 518 executives, only 15 percent let AI take action with zero human approval, while 38 percent said unsupervised AI had already cost them real time, revenue, or reputation.

Zapier’s guide to adding tools to an AI by Zapier step documents the tool setup flow, including the approval toggle and field modes. Zapier’s announcement of AI by Zapier maps the old Agents ingredients onto the new step.

Prerequisites

• A Zapier account with access to the AI by Zapier step. Multi-step Zaps require a paid plan.
• One Zap using an AI by Zapier step. The example is support-ticket triage: a ticket arrives, the AI reads the record, drafts a reply, and sends it.
• Connected accounts for the tools you plan to gate: a CRM or spreadsheet for reads, and an email app for sends.
• A named approver. Approval pauses a run until someone approves it, so decide who watches the queue.
• A test record you can safely send, update, and delete. Never test against a real customer record.

Step-by-step guide

Step 1: Classify every tool as read or write

List each tool with one label: read or write. Reads only fetch data: look up a customer record, search a price list, fetch an order status. Writes change the world outside the Zap: send an email, create a reply, update a CRM field, charge a payment, delete a row. The rule from Zapier’s help page maps directly onto this list: writes get approval, reads do not.

Treat borderline cases as writes: updating a ticket status is a write, because the AI chooses the new status and the customer may see it. When in doubt, gate the tool.

Step 2: Write a prompt that names the tools

Create a Zap with a trigger that fits your scenario, then add the AI by Zapier step. In the prompt field, describe the job in plain language and name the tools by function:

You triage new support tickets. Use the CRM lookup tool to find the customer record and the order status tool to check the order. Draft a short reply from the record. Do not invent order details that are not in the lookup results. Use the email tool only for the final reply, and the ticket update tool to set the status you recommend.

Naming the tools matters: the approver must see what the agent was trying to do.

Step 3: Add a read-only tool and leave approval off

In the Tools and Knowledge section, click Add tool to open the Add tool dialog. Under Tool type, select App action, then choose the app, the app action, and the connected account. For the CRM lookup, select your CRM app, its record lookup action, and the account the Zap should use.

For each input field, choose: set a specific field, let the agent choose from a list, let the agent determine it at runtime, or exclude it. For a read tool, map the lookup key from the trigger, such as the customer email from the ticket, as a specific field. Letting the agent determine a lookup key at runtime is how a triage agent looks up the wrong customer, and no approval toggle will catch it, because reads are ungated by design. Leave Require approval before running off, click Add tool, then test the lookup on a sample ticket before adding any write tool.

Step 4: Add a write tool and turn approval on

Add the email tool the same way: Add tool, App action, your email app, its send action, and the connected account. Before you click Add tool, toggle on Require approval before running. People skip this step because the toggle sits in the same dialog as the field configuration and it is off by default. Check it deliberately, tool by tool: turning it on for one tool does not gate the others.

Lock down fields that must never be improvised. Set the recipient from the trigger or the verified lookup result as a specific field, never as a field the agent determines at runtime. Let the agent determine only the message body; the recipient and any money or date field should come from real data. That division makes an approval request judgeable: the approver checks the draft text, not whether the email goes to the right person.

Add the ticket update tool the same way, with approval on, and set its status field to let the agent choose from the list of valid statuses rather than determining free text.

Step 5: Set the runaway brake before you publish

Decide your per-run task limit. Zapier’s migration guide states the default: a run exceeding 75 tasks pauses for review, and the limit is adjustable up to 500. The default suits a triage Zap, which should need a handful of tool calls per ticket. A run hitting 75 tasks signals a problem: the agent is looping, retrying a failing tool, or calling tools it does not need. Raising the limit to 500 without investigating hides that signal.

Set the limit in the step’s settings. A paused run waits for a person, and Zap History shows the tasks consumed, broken down by tool call, model tier, and step. Also check the model tier: Advanced and Premium tiers bill tasks at their tier rate per run, even without tools. Approval and billing are separate dials, so set the tier for quality, approval for risk, and the task limit for the worst case you will fund.

Step 6: Test both approval and rejection

Publish nothing until you have tested both outcomes. Run the Zap on a test ticket and approve the request from your Zapier account, confirming the email sends and the status updates. Run it again and reject the approval. Confirm the gated tools do not run after a rejection, and check what later steps do: do they stop cleanly, or proceed as if the reply had been sent? A Zap that marks a ticket resolved after a rejected reply reports success for work that never happened.

Test the read path too: a run with a successful lookup should not pause on ungated read tools. Test with the real approver too, confirming they can tell what the agent wants to do.

Step 7: Run the approval queue as a team process

Agree on three things before the Zap goes live. First, a rota: who approves during working hours, and who covers absence. Second, a response target: how long a paused run may wait before it is escalated or rejected, because a reply approved three days late is often worse than no reply. Third, a weekly review of Zap History for tools approved 100 times in a row, which are candidates for tighter field locks or a documented ungating decision.

For teams, add the admin layer: Zapier documents that admins can require AI-step Zaps to go through a publishing approval process, and can enable or disable tool calling at the account level. Runtime approval and publishing approval answer different questions, and neither replaces the other.

Troubleshooting

Approval requests never arrive

Approvals surface in your Zapier account and by email, so a missing approval is usually a routing problem. Confirm which account owns the Zap and which inbox the approval email goes to, then run a test ticket yourself and approve it from your own account. Also verify the tool itself: open it and confirm Require approval before running is on, since the toggle is off by default and set per tool.

The Zap pauses constantly and the team stops approving

A queue full of pauses usually means approval is set on the wrong tools. Audit each toggle against your read-or-write classification from Step 1. The usual culprit is a read tool gated during setup, so every run pauses before doing anything risky. Turn approval off for reads and keep it only on writes. Shorten the path with a rota and a response target, or split the Zap so low-risk writes run separately from customer-facing sends. Never solve approval fatigue by turning everything off.

A tool runs without approval even though you set it

Check three things in order. First, that you edited the right tool instance: if the same app action was added twice, one instance may be gated while the other runs free. Second, that you published and tested after changing the toggle, not just changed it in a draft. Third, whether the Zap was migrated from the old Agents product: migrated tools inherit the old all-or-nothing behavior, and Zapier’s guidance says tools run without pausing unless you switch approval on for each one. After a migration, audit every toggle from scratch.

A run pauses at 75 tasks and never finishes

Treat the pause as a diagnosis, not an error to clear. Open Zap History for the paused run and read the task breakdown by tool call. A single tool called dozens of times usually means the agent is retrying a failing lookup or looping on an ambiguous prompt. Fix the prompt, tighten the field mappings, or add a filter step before the AI step so the agent never sees records it cannot handle. Raise the limit toward 500 only once you understand the loop.

The approver approves, but the wrong email still goes out

Approval judges the action, not the data, so a wrong recipient or amount usually means a field was left for the agent to determine at runtime. Change every field carrying identity, money, or dates to a specific field mapped from the trigger or a verified lookup, leaving only the draft text to the agent’s judgment. Retest the rejection path too, and add a filter after the AI step that only continues when approval was granted.

FAQ

Should I gate every tool to be safe?

No. Gating every tool, including reads, fills the queue with pauses that carry no risk, and a queue nobody reads is worse than a short queue that gets attention. Gate writes and customer-facing actions, and leave reads ungated.

What is the difference between per-tool approval and Human in the Loop?

Per-tool approval is a toggle inside the AI by Zapier step that pauses a run before one specific tool runs. Human in the Loop is a separate Zapier tool that pauses a Zap at a step so a human can review before the workflow continues. Use per-tool approval for “should the agent use this tool right now?” and a Human in the Loop step for “should this workflow continue at all?”

Does per-tool approval work on migrated Agents?

Migrated agents become Zaps with a trigger and one AI step, but their tools do not automatically gain per-tool approval. Zapier’s migration guidance says tools run without pausing unless you switch approval on for each one. After any migration, set each tool’s toggle deliberately, then test both approval and rejection paths.

Who should approve when the Zap owner is away?

Whoever owns the rota, not whoever happens to be online. Name a backup approver before the Zap goes live, and make sure the backup has tested approvals on a test record. A queue with a single approver fails during leave, and the team eventually works around it.

Can I approve from email, or do I need to open Zapier?

Zapier’s human-in-the-loop guidance describes approvals arriving by email, with the decision made in your Zapier account. Treat the email as the notification and the Zapier account as the decision point: open the approval there, read what the agent wants to do, then approve or reject. Do not approve from a message preview alone, because it may not show the full tool inputs.

What should I check in Zap History each week?

Three things: which tools were approved without comment, which runs paused at the task limit, and whether any run’s task breakdown shows one tool dominating the cost. Paused runs point to prompt or mapping problems. A dominating tool points to a loop or a retry problem.

Conclusion

Draw the line between reads and writes before the Zap is built, not after the first incident: classify each tool, gate the writes, leave the reads alone, keep the task limit at the default until a pause proves otherwise, and test both approval and rejection before anyone depends on the Zap.

If your next step is to make the whole workflow resilient rather than just gated, read our Zapier durable workflows tutorial for building Next Gen Zaps that keep running, and our Zapier to n8n migration guide if you want to compare the approval model with a self-hosted alternative. If you want the fully self-hosted route, the complete n8n guide covers installing and securing your own instance.

Frequently asked questions