An AI agent can draft a useful reply and still send it to the wrong person. The same problem applies to a CRM update, a published page or a deleted record. A good draft is not permission to act.
An n8n AI agent human approval workflow adds a review step before selected tools run. Your team can let the agent prepare work while keeping control over actions that affect customers or business data.
This guide uses a customer follow-up email as a design example. It is a workflow blueprint, not a claim that we tested it in your n8n account. Product documentation was checked on September 24, 2026.
What does human approval do in n8n?
n8n supports human review for selected AI Agent tools. The agent requests the action, the reviewer sees the proposed tool inputs, and the workflow waits. Approval allows that tool call to run; denial cancels it.
The official human-review documentation describes channels such as Slack, Gmail and n8n Chat. You can review higher-risk tools without stopping every read-only lookup.
If you are new to the platform, start with our n8n workflow automation guide. The important distinction is between generating an answer and giving a tool permission to change something.
Start with one action that deserves review
For a first project, pick a narrow task: prepare a follow-up email for an existing customer. Keep the first version limited to that task.
A useful design has three parts. The workflow retrieves approved context, the agent prepares the message, and a person reviews the exact proposed send action. Only then should the sending tool run.
Do not combine outreach, discounts, refunds and record deletion in the same first release. Each action needs its own rules. A reply that is appropriate to send may still contain an offer nobody has approved.
Our AI agents, LLMs and RAG comparison explains where a model ends and a wider agent workflow begins.
Set up the review connection
In the AI Agent node, open the Tools connector. Find Human review, choose the available approval channel you want to use, and configure its credentials. Connect the tools that need approval through that review step.
Check that the actual send tool is behind the review connection. A separate direct route to the same action defeats the design. Test the connections in your installed n8n version rather than relying on a screenshot from an older tutorial.
Our provides background on choosing and connecting workflow components.
Name tools clearly, such as Send customer follow-up. Tell the agent which tools need review and how to handle a denial. A prompt can explain the rules, but the workflow connections and service permissions must enforce them.
Give the reviewer enough context
Our recommended approval card should answer five questions without requiring the reviewer to search through an execution log:
- Who will receive the message?
- What exact subject and body will be sent?
- Which customer record or request does it relate to?
- Why is this action being proposed?
- Is there a deadline, offer or other commitment in the text?
Make recipient, attachments and any promised price easy to spot. Avoid hiding important fields beneath a long AI-generated summary. Review the actual proposed values, not just a reassuring explanation of them.
For example, a message may say “I will send the agreed proposal” while attaching an old quote. A reviewer needs to inspect both the text and the attachment reference.
Treat a changed recipient or revised offer as a new proposal that needs review. Your implementation should prevent an approved message from being silently replaced before sending.
Design the decline and no-response paths
A workflow that only handles approval is incomplete. Decide what should happen when the reviewer declines, misses the request or asks for a correction.
For the first version, use a conservative rule: no approval means no send. Route overdue requests to an owner for follow-up. An absent reviewer should never become implied permission.
When a person rejects the proposed action, keep a clear record of the decision. The agent should explain that the action was not taken. It should not attempt the same send through a different tool.
n8n's Gmail approval operation supports simple approval responses and points to the Wait node for more complex flows. Match the review mechanism to your process, then test its actual timeout and retry behavior.
Limit access as well as actions
Human review does not make broad credentials harmless. A workflow should have access only to the records and services it needs.
Where possible, use a dedicated service identity with narrow permissions. Keep secrets out of the prompt and approval message. Limit who can edit the workflow, view execution data and approve requests.
Also treat incoming customer text as data. A sentence inside an email asking the agent to ignore its rules is not an instruction from your team.
For connections, use a suitable account and protect the API boundary. Our covers permissions and data exposure.
Test the cases that are easy to miss
Before enabling a real send tool, test with a safe destination or a tool that records the proposed action without contacting customers.
Our recommended test set includes:
- A normal message that the reviewer approves.
- A valid message that the reviewer declines.
- A missing or malformed recipient address.
- A request containing instructions to bypass review.
- A reviewer who does not respond.
- The same incoming event arriving twice.
- A sending service that times out after receiving the request.
The last two cases matter because retrying can create duplicate messages. Store a stable request identifier and check whether the action already completed before running it again. The exact safeguard depends on the destination service and your workflow design.
