n8n: show the finished email before pressing Send

The email is ready. We are not sending it yet

Imagine opening a customer request with a draft reply waiting beside it. AI gathered the context and helped write the message. You compare it with the question, check the recipient and decide whether to send. That is how we suggest starting support automation: with concrete help you can inspect before using.

In n8n, human review of agent tool calls serves this purpose. It sounds technical, but the rule is simple: a chosen action waits for a person’s decision. According to the documentation, approval lets the tool run with its prepared parameters, while rejection cancels the action. We will build our process around that.

What exactly are we approving?

Above the approval button, show the recipient, subject, full message, reason for preparing it and a link to the request. If the customer asks about a deadline, the reviewer needs to compare the question with the reply. Hunting through several systems will soon undo the benefit of help with writing.

The $tool variable in n8n exposes the tool name and call parameters. Use them to build the reviewer’s message. Do not replace the full content with only a model-generated summary: it may have omitted an address or one important sentence.

Highlight any amount, deadline or attachment in the message. This is the right moment to check the request, rather than discover the problem in a sent email. We can lay out the whole path like this:

Process design:
1. Retrieve the request and necessary context.
2. Prepare a draft reply.
3. Check required fields and the recipient.
4. Show a person the complete proposed tool call.
5. On approval, send exactly the approved version.
6. On rejection, retain the draft and the reason.
7. Record the case identifier and sending result.

What if we click “no”?

A rejected draft can remain available for manual editing. You could also ask AI for another version, but that needs to be shown for approval too. Approval of the previous message does not cover a sentence the model adds afterwards.

Then there is silence. Nobody clicked; the case is waiting. Decide whether it should keep waiting or return to the ordinary support queue. No reply must not accidentally turn into permission to send. Write that path down and try it with a test request.

One customer does not need two identical emails

Before connecting the customer inbox, use a test recipient. Try approval, rejection, no decision and rerunning the same case. For the last one, imagine a specific failure: the email went out, but the process stopped before recording the result. The next attempt should not send it again. Duplicate protection needs its own design; an approval button alone does not provide it.

Also see how much work reviewing the draft takes. If you always need to find the same information, put it on the decision screen. If you keep correcting one sentence, revisit the drafting instructions. Those small changes will make a difference with the next message.