n8n Gmail Node:
build inbox automations without the mess.

Configure Gmail Trigger for a narrow inbox slice

Select Message Received, choose a poll schedule, leave Read Status at unread-only while tuning, and start with a maximum of 10 emails per poll. Add a sender, label, or search condition only when it describes the real lane you want to automate. The point is to make the first run small enough that every item can be inspected.

Get the message only when the trigger payload is not enough

Add Gmail → Message → Get and map its Message ID from the trigger, for example {{$json.id}}. n8n's message documentation says the simplified form is equivalent to Gmail API metadata and returns IDs, labels, and headers. Turn Simplify off only when the next step genuinely needs the raw response, then map the smallest body, sender, subject, and thread fields required.

Return a small, boring classification

Keep categories stable: reply, review, reference, and ignore are enough for a first pass. If an AI classifier is involved, require a contract like this and reject anything outside the enum:

{
  "category": "reply",
  "confidence": 0.86,
  "reason": "Customer asks for a status update",
  "needs_reply": true
}

This JSON is an application-level output contract, not a special Gmail setting. Use a Switch or validation step after it. A classifier can interpret; it should not decide that a recipient, attachment, or send action is automatically authorized.

Claim the inbound message before touching the draft

Use a durable Postgres table as the workflow's action ledger. The n8n Postgres node supports Execute Query, and PostgreSQL's INSERT documentation defines ON CONFLICT and RETURNING. Create the table once, with a unique key, then make the reservation the first side-effecting step after classification:

CREATE TABLE gmail_automation_runs (
  idempotency_key text PRIMARY KEY,
  message_id text NOT NULL,
  thread_id text,
  purpose text NOT NULL,
  state text NOT NULL,
  draft_id text,
  category text,
  decision_reason text,
  updated_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO gmail_automation_runs
  (idempotency_key, message_id, thread_id, purpose, state)
VALUES
  ($1, $2, $3, 'inbox-reply-draft:v1', 'processing')
ON CONFLICT (idempotency_key) DO NOTHING
RETURNING idempotency_key;

Set idempotency_key to the inbound Message ID plus :gmail-inbox-draft:v1. Bind the values through the Postgres node rather than concatenating email text. A returned row is the reservation. If the key already exists, read its record and stop: drafted with a draft_id is a handoff, terminal is a no-reply decision, and processing or error is not permission to create another draft.

Create a draft, then persist its ID

For the reply branch, use Gmail → Draft → Create. n8n exposes fields for Subject, Text or HTML email type, Message, recipients, aliases, Send Replies To, attachments, and Thread ID. Map the original thread ID when the reply belongs in the existing conversation. Keep the To address derived from the message being answered or an approved routing rule, not from a free-form model guess.

Immediately after Draft Create returns, run a Postgres update and require it to affect the reserved row:

UPDATE gmail_automation_runs
SET state = 'drafted', draft_id = $2, updated_at = now()
WHERE idempotency_key = $1 AND state = 'processing'
RETURNING idempotency_key, draft_id;

If Draft Create fails, record error when that is safe to do, but do not add the terminal source label. If Gmail created a draft and the database update then timed out, treat the run as uncertain: inspect Gmail and the ledger, attach the existing draft ID, and only then continue. Never rerun that branch automatically just because the last node returned an error.

For an ambiguous call, stop the worker first. Read the ledger: if already drafted, verify its ID; otherwise mark the unresolved reservation uncertain. After a human verifies the existing Gmail draft belongs to this message and purpose, bind that draft ID as $2 in the second update. These queries never call Draft Create. Require a returned row; otherwise reread and stop rather than overwriting a competing transition.

UPDATE gmail_automation_runs
SET state = 'uncertain', updated_at = now()
WHERE idempotency_key = $1 AND state IN ('processing', 'error')
  AND draft_id IS NULL
RETURNING idempotency_key;

-- Run separately, only after verifying the existing draft.
UPDATE gmail_automation_runs
SET state = 'drafted', draft_id = $2, updated_at = now()
WHERE idempotency_key = $1 AND state = 'uncertain'
  AND draft_id IS NULL AND NULLIF($2, '') IS NOT NULL
RETURNING idempotency_key, draft_id;

The Gmail draft guide makes the boundary explicit: a draft is unsent, it carries the DRAFT system label, and it cannot receive another label. When a draft is sent, Gmail deletes the draft and creates a new message with a new ID and the SENT label. Store the draft ID separately from the inbound Message ID.

Add a label to the source message, not the draft

Only after the handoff is durable, use the Gmail Message operations Add Label action. In the reply branch, that means after the row contains the returned draft_id. In a no-reply branch, first update the row to terminal with the decision, then label the source message. If labeling fails, retry the label operation against the existing ledger row; do not create a second draft.

For no-reply decisions, bind the validated category and concise reason as $2 and $3. Require the returned row before labeling:

UPDATE gmail_automation_runs
SET state = 'terminal', category = $2, decision_reason = $3,
    updated_at = now()
WHERE idempotency_key = $1 AND state = 'processing'
  AND draft_id IS NULL AND NULLIF($2, '') IS NOT NULL
  AND NULLIF($3, '') IS NOT NULL
RETURNING idempotency_key, category, decision_reason;

Choose message or thread deliberately. Google's label documentation explains that a label can be associated with messages and threads, but labels only exist on messages. Adding a label to a thread applies it to all existing messages in that thread; messages added later do not inherit it automatically. If the workflow means “this particular inbound message was processed,” label the message. If it means “this whole conversation is in a review lane,” use the thread-level behavior and verify what is actually covered.