BLOG
To require human approval for an n8n AI agent, connect the tools that perform consequential actions to the AI Agent’s Human review step and configure a review channel. Before releasing the workflow, verify that a person sees the complete proposal, can decline it, and that the executed action matches the approved proposal. A generic “May I continue?” prompt is not enough for changing a CRM record or sending a client message.
Approve a concrete proposal: the reviewer should identify the recipient, affected record, previous and proposed values, and expected effect. If they must reconstruct these facts in another system, the review request is incomplete.
Place review immediately before the action
n8n’s Human-in-the-loop documentation describes pausing before selected tool calls. Approval releases a proposed call with its parameters; denial cancels that action and informs the agent. This allows a team to review tools with meaningful effects rather than every harmless step.
Separate consultation, preparation, and execution. Looking up a catalog item or drafting a summary can produce the proposal. Sending an offer, moving a deal to another owner, or deleting a record has a different effect. List the actions your team wants reviewed and identify the node or service that actually performs each one. The control must cover that entire route, including indirect calls available to the agent.
Avoid giving the agent an alternative tool with the same write capability that bypasses review. If it can choose between “send message” and “call the messaging API,” protecting only the first tool leaves a second path. Tool labels and prompt wording cannot prove that all execution paths are covered; inspect the architecture and available credentials.
| Action | Proposal shown to reviewer | Decision required |
|---|---|---|
| Send message | Channel, recipient, final text | Check content and audience before sending |
| Update CRM | Record ID, field, old and new values | Confirm identity and meaning of change |
| Delete data | Exact object and deletion effect | Assess necessity and recovery |
| Consult information | Access scope | Decide if a fresh approval is needed |
Connect the AI Agent to a review channel
In the AI Agent’s Tools connector, find Human review, choose a channel, set credentials, and attach the tools that require approval. These are the steps described by n8n; confirm labels in the version you actually run. Do not assume the review step applies automatically to unrelated nodes or APIs elsewhere in the workflow.
Choose a channel used by the people who decide. A team may use a restricted Slack conversation; another may use Telegram, email, or n8n chat. Determine who receives a request, how pending decisions are monitored, and who may act. Availability of a channel integration does not prove that every person in the channel is authorized to approve every business action.
Check prerequisites outside the agent: service account, credentials, access rights, connectivity, and any applicable channel cost. A subscription to an application is not automatic authorization to use its API. There is no universal minimum price, plan, or version for every combination of agent and review channel; verify the requirements for the configuration being installed.
Show the exact parameters under review
The review step exposes $tool.name and $tool.parameters to compose the request. They can show the tool and its proposed input. The name is the tool node’s name on the canvas; parameters include fields defined through $fromAI(). A concise draft is:
Tool: {{ $tool.name }}
Proposed input:
{{ JSON.stringify($tool.parameters, null, 2) }}Add context a reviewer can understand. A JSON value such as stage_id can be technically complete while failing to tell a sales manager which pipeline stage a client will enter. Show the stage name alongside its identifier, while preserving a verifiable link between the displayed proposal and the input executed after approval.
n8n’s $fromAI() guidance explains model-filled tool parameters and their limits. The function does not work in every workflow field and has documented exceptions. A parameter description helps the model choose a value; it does not validate the value. Check required fields, allowed destinations, and the relationship between IDs before presenting or executing a proposal.
Keep stable facts under workflow control when possible: project, account, permitted recipient list, and available operation. Let the agent propose the content it actually needs to formulate. For a CRM update, a record ID may come from a verified lookup while a suggested note comes from the agent. The implementation then checks that both belong to the same request.
Walk through one CRM proposal
Imagine an agent summarizing a sales conversation and proposing to move a deal to “proposal requested.” The manager’s review message shows the deal, customer, current stage, proposed stage, and the conversation evidence. The manager can evaluate the change without relying solely on the phrase “the customer is interested.” This is an architecture example, not a tested integration with a particular CRM.
- Look up the deal and its current state.
- Prepare a proposed change with a reason.
- Validate required fields and allowed destination.
- Show the exact effect to the reviewer.
- Apply that proposal only after a valid approval.
- Read the CRM response and classify success, failure, or uncertainty.
A local proposal record might hold a proposal ID, record ID, field, previous value, proposed value, and a pending decision. These are suggested fields for your own process; they are not the standard response of the Human review node. Give each proposal a stable identity so that a late decision cannot be accidentally applied to a newer version.
The deal may change during the review delay. Recheck relevant destination state immediately before the write. If it differs from what was shown, present the change to the reviewer and request a decision about the current proposal. Approval based on an old value is not automatically approval of a different effect.
Apply the same rule to messages. If the agent rewrites the text after approval, a reviewer needs to see the new final text. Approval is not open permission to change channel, recipient, attachment, offer, or commercial condition. Bind these values to the concrete proposal that will be executed.
Keep denial, silence, and execution failure separate
The agent’s operating prompt should say which tools require review and how to respond to a denial. It should report the received result, ask for clarification when appropriate, and respect the decision. If the review result says only “denied,” the agent must not invent a reason or call a different tool to get around the control.
A workable instruction is: “If a proposal is denied, do not execute that action. Report the denial without inventing a reason. Use the reviewer’s comment when one is available. Prepare a revised proposal only when new information or a request justifies it, and submit it for review again.” This text is guidance for the agent, not a technical authorization mechanism.
Silence needs its own path. The n8n Wait node can resume an execution after a configured period. Resumption is not approval. A custom review built with Wait and a webhook must authenticate the returning decision and test it explicitly before reaching any write. A time limit should never silently become an “approve” branch.
As an implementation policy, decide what happens to expired proposals: stay pending, expire, or return to a responsible person. Record the distinction between nobody responding and somebody approving. This lets a team recover work without performing unreviewed actions after a timeout.
Approval does not make the destination API reliable. n8n documents error workflows and execution inspection for failure handling. Store approval separately from the confirmed outcome. If a response is uncertain, inspect the destination before repeating an update or message that may already have occurred.
Check chat behavior and the audit trail
The n8n Chat node supports sending and waiting for a response, including approval options. It requires the Chat Trigger response-node configuration, and its documentation notes limitations for embedded chat, sub-workflows, and some subagent uses. Do not assume a chat example applies to every agent architecture.
Conversation history can help investigate a decision but does not alone prove authorized identity, binding to a proposal, retention, or record integrity. For an operational trail, keep the proposal, received decision, identity the channel actually exposes, response time, and destination outcome. Confirm which data the channel provides before promising a complete audit record.
Limit what a reviewer sees to what they need for the decision. They may need the proposed commercial content without seeing tokens, passwords, or unnecessary personal data. An approval button does not by itself establish legal compliance; appropriate access and retention depend on the business process.
Test every decision path before release
- Confirm that every tool capable of the reviewed action passes through the gate.
- Show complete proposals with understandable identifiers.
- Approve and compare the actual effect with what was displayed.
- Deny and verify that the action did not happen.
- Let the request expire and verify that silence does not release it.
- Change the destination record during review and test the stale proposal.
- Simulate a destination error and an uncertain response.
- Check who can review, how decisions are recorded, and how pending work is recovered.
Use a controlled destination, fictional data, and actions that cannot affect customers. Save what happened in each scenario, including workflow version and input parameters. A demonstration in which everyone clicks Approve does not test denial, expiry, or failure after authorization.
Frequently asked questions
Must a person approve every agent lookup?
Define policy by effect and context. An authorized information lookup may be treated differently from sending or modifying data. Identify the routes that perform actions and put required review before those routes.
Is a sentence in the System Prompt enough?
No. The prompt guides the agent; execution control belongs in the workflow and the tools it can access. Review alternative routes, destination permissions, and data released by an approval.
Does denial end the entire workflow?
It cancels the reviewed action. What the workflow does afterward—inform the user, record the decision, or prepare another proposal—depends on the implementation. Verify the actual route.
Does approval guarantee the CRM was updated?
No. It authorizes a proposal. The write still needs a destination response and, where necessary, readback. Keep authorization and completion separate so errors can be recovered without repeating the action blindly.
Start with one recognizable action
Choose an operation the team can identify and verify, such as updating one specific CRM field. Document the proposal, decision, and destination result. Test denial and failure before expanding the scope. Human review works when the person knows exactly what will happen and the implementation preserves that link through execution.
