A safe AI email workflow creates a proposal, not a sent message. It gives that proposal a stable approval ID, stores it with a pending state, shows a reviewer enough context to decide, waits for a response, and only then allows one guarded send.
Short answer: in n8n, use Gmail Send and Wait for Approval for a simple approve-or-reject gate. Use a Wait node with On Form Submitted plus a Data Table when the reviewer also needs to edit, reject with a reason, or let the request expire.
| Need | Best starting pattern | Important limit |
|---|---|---|
| Approve or reject only | Gmail Message → Send and Wait for Approval | Good for a simple decision, not a full edit-and-escalation process |
| Approve, edit, reject, or timeout | Data Table + reviewer notification + Wait form | The form link is sensitive and the documented form mode has no authentication setting |
| Identity-proof approval | Wait webhook with Basic, Header, or JWT auth, or an authenticated internal portal | More setup, but the reviewer identity is stronger than a typed email address |
The safe workflow architecture
Trigger or incoming request → AI creates proposed subject and body → Validate recipient, policy, and required fields → Data Table: insert approval_id with status = pending → Notify reviewer with safe context and resume URL → Wait: On Form Submitted, with a time limit → Switch: approve / edit / reject / timeout → Data Table: pending → sending → Gmail: send once → Data Table: sent, message_id, reviewer, timestamps
This guide begins after an AI draft already exists. It is separate from classifying and routing incoming email. The approval gate controls an outbound action that could reach a customer, supplier, applicant, or lead.
Why the model must not connect directly to Send
A language model can produce fluent text while using the wrong price, recipient, promise, date, or tone. Prompt instructions help, but they do not create an operational control. If the model node connects directly to Gmail Send, a bad draft can leave the business before anyone sees it.
Put validation and approval between generation and delivery. Validate machine-checkable rules first, such as an allowed recipient domain, non-empty subject, maximum length, banned attachments, and required account references. Then ask the human to judge the parts that need context.
Step 1: start with the simplest n8n setup
For a small team that does not want to maintain a server, n8n Cloud is the easiest starting point. n8n describes Cloud as the option where it handles the infrastructure. Create one workflow, connect the AI provider you already use, add a Gmail credential, and test only with internal addresses until every branch behaves correctly.
If the decision is only approve or reject, test Gmail Message → Send and Wait for Approval first. The current Gmail node supports an Approve Only mode and an Approve and Disapprove mode. n8n itself recommends the Wait node for more complex approvals, which is the full pattern below.
Step 2: turn the AI output into a real draft record
Add an Edit Fields node after the model. Keep only the fields the approval stage needs, then generate a stable approval_id. Use a UUID or another collision-resistant ID. Do not use the recipient address or current timestamp by itself.
approval_id recipient subject_proposed body_proposed source_record_id status created_at expires_at
Set status = pending. Store the proposed subject and body in a Data Table before notifying anyone. This durable row lets an operator see what is waiting even when the workflow execution is paused or the reviewer email is lost.
Gmail also has a separate Draft resource. The current n8n Gmail Draft operations document create, delete, get, and list. They do not document a built-in Draft Send operation. Use a provider-side Gmail draft only as an optional inspectable copy unless you deliberately add the Gmail API users.drafts.send call. Do not assume a Gmail Draft node automatically delivers the draft later.
Step 3: create the approval table
For a first version, create an email_approvals Data Table with these columns:
approval_id source_record_id recipient subject_proposed body_proposed subject_approved body_approved status reviewer decision_reason created_at decided_at sent_at provider_message_id
The Data Table node can insert, get, update, and upsert rows using conditions. That is enough for a small approval ledger. If the workflow has high concurrency, regulatory audit requirements, or several systems changing the same state, move the ledger to a database with transactions, unique constraints, and access controls.
Step 4: notify the reviewer and pause
Send the reviewer an internal email containing the approval ID, recipient, proposed subject, a safe excerpt, expiry time, and the Wait form link. The Wait node exposes $execution.resumeUrl, which is unique to the execution. The node that sends this link must run in the same execution as the Wait node.
Configure Wait → On Form Submitted with:
- A required dropdown named
decisionwithApprove,Edit, andReject. - An optional text field for the approved subject.
- An optional textarea for a revised body.
- An optional rejection reason.
- A reviewer identifier for the audit log.
- Limit Wait Time set to the business deadline, such as 24 hours.
If the reviewer chooses Edit but provides no replacement body, do not send. Route the item back to pending or a manual queue. n8n's form fields are not documented as conditionally required, so enforce this rule after submission with an If or Switch node.
Treat the resume URL like a secret. The Wait form documentation does not list the Basic, Header, or JWT authentication choices available in the webhook mode. Do not post the link in a broad channel. For sensitive approvals, use an authenticated webhook or internal portal and record the authenticated user.
Step 5: branch every possible outcome
| Outcome | State change | Next action |
|---|---|---|
| Approve | pending → approved |
Copy the proposed subject and body into approved fields |
| Edit | pending → approved_edited |
Validate and store the human replacement before sending |
| Reject | pending → rejected |
Store the reason; never connect this branch to Send |
| No form data at the limit | pending → expired |
Escalate or create a fresh approval request, never auto-approve |
The Wait node automatically resumes when its configured time limit is reached. Check for a valid submitted decision before treating the execution as approved. Missing form data belongs on the timeout branch.
Email is the clearest reviewer channel for this example. Slack, Telegram, Google Chat, email, or a webhook can carry an alert, but do not assume every notification node has the same approval features. Keep the decision state and send guard in the workflow even when the alert channel changes.
Step 6: prevent duplicate clicks and duplicate sends
Before Gmail Send, add a Data Table Update node with All Conditions:
approval_id equals {{ approval_id }}
status equals approved OR approved_edited
Update:
status = sending
In practice, use separate approve and edited branches if the node cannot express the OR cleanly. Continue only when one row was updated. If the row is already sending, sent, rejected, or expired, stop. This conditional claim protects the normal single-execution path from a second click, duplicated callback, or later retry.
After Gmail succeeds, update the same row to sent and store the provider message ID and sent_at. Do not manually retry from the Gmail node. Restart recovery from the state check so the send guard runs again.
n8n documents conditional Data Table updates, but it does not promise compare-and-set or transaction semantics across competing executions. If two executions could claim the same approval at exactly the same time, use a database transaction, unique constraint, or another state store with an atomic claim. For a Gmail-specific alternative, create one provider draft and send that immutable draft ID through the Gmail API. Google documents that sending automatically deletes the draft and creates the Sent message, so the same existing draft is no longer available for a second send.
Gmail Message Send does not expose a provider idempotency key in the documented node fields. Add the approval ID to an internal reference in the subject or footer so an operator can search Sent mail. If the network times out and you cannot tell whether Gmail accepted the message, set status = send_unknown, search by that reference, and reconcile before any retry.
Handle failure after approval
| Failure | Safe response |
|---|---|
| Recipient or payload validation fails | Return to review with a clear reason; do not claim the send |
| Credential or definite provider rejection | Mark send_failed, alert the owner, and repair before a guarded retry |
| Provider timeout with an uncertain result | Mark send_unknown and search the provider before retrying |
| Email sends, audit update fails | Keep the row at sending; reconcile by approval reference and provider message ID |
| Reviewer link expires | Create a new approval request and invalidate the old one |
This is the same reason duplicate-safe API retries need a persistent ledger. A timeout is not proof of failure. Use the deeper n8n API retry guide when the final email provider is called through HTTP Request or another state-changing API.
Test the approval workflow before using real recipients
| Test | Expected result |
|---|---|
| Approve unchanged | One email uses the proposed subject and body; audit row becomes sent |
| Edit subject and body | Only the human-approved values are delivered and stored |
| Choose Edit with no body | No send; request returns to review |
| Reject | No send; reason and reviewer are recorded |
| Let the request expire | No send; status becomes expired and the owner is alerted |
| Submit or click twice | One email; if parallel tests produce more, move the claim to a transactional store |
| Fail Gmail after approval | The workflow records failed or unknown, alerts an owner, and does not blind-retry |
| Retry the execution | A sent or sending state blocks another message |
Privacy and audit rules
The Wait node offloads paused execution data to the n8n database and reloads it when the workflow resumes. That means every upstream field carried into the wait can remain in stored execution data. Reduce the item before the wait. Do not carry a full mailbox thread, attachments, payment details, health information, or unrelated customer history when the reviewer only needs a short excerpt and a secure system link.
- Store the approval ID, decision, approved content hash or final content, reviewer, and timestamps.
- Treat a reviewer name typed into an open form as self-reported, not authenticated identity.
- Use n8n's production execution data redaction when operators should not see node inputs and outputs.
- Set a retention policy for the approval table and execution history.
- Keep successful execution data only as long as operations and audit needs require.
n8n enables pruning of finished execution data by default. Its documented self-hosted defaults are 14 days by age and 10,000 finished executions by count, while waiting executions are not eligible for pruning. The approval timeout is therefore an operating control as well as a reviewer deadline.
Practical questions
Can the AI send automatically after enough approvals?
You can later auto-send low-risk categories, but earn that exception with real review data. Start by measuring edit rate, rejection rate, send failures, and the types of mistakes reviewers catch. Keep high-value, legal, financial, hiring, complaint, and unusual-recipient messages behind approval.
Should the approval live in email or chat?
Use the channel the responsible person already monitors, but keep the durable state in the workflow or business system. An alert is not the audit record. For a simple decision, Gmail's built-in approval operation is convenient. For edits, timeouts, and stronger identity, use the Wait pattern or an authenticated portal.
Is the n8n execution history enough for an audit?
Usually not by itself. Execution retention can be changed or pruned, and open form identity may be self-reported. Keep a compact business audit row with the approval ID, final decision, final approved content or hash, reviewer identity level, timestamps, and provider result.
Sources checked
- n8n Cloud and self-hosted setup choices
- n8n Wait node resume modes, unique resume URL, authentication, forms, and time limits
- n8n Gmail Send and Wait for Approval and Message Send operations
- n8n Gmail Draft operations
- n8n Data Table conditional row updates and upserts
- n8n workflow execution saving, timeout, and redaction settings
- n8n execution data reduction and pruning behavior
- Google Gmail API draft creation, update, and send behavior
n8n Cloud for small teams
Test the approval gate without maintaining a server
n8n Cloud is the simplest starting point if you want to focus on review states, safe sends, and testing instead of hosting. Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.
Need the approval states mapped before launch?
Send the trigger, draft fields, reviewer channel, email provider, deadline, and failure rules. I will help define the smallest approval workflow that keeps customer email under human control.
Map the approval gate