n8n Slack approval workflow with a timeout and an escalation path.

The n8n Slack node has a Message operation called Send and Wait for Response. It posts a message, pauses the execution and resumes when someone responds. Set Response Type to Approval and Type of Approval to Approve and Disapprove so a reviewer can decline as well as approve. You can rename the buttons, for example to “Approve refund” and “Decline”.

The node can collect the decision in two ways. By default the buttons are links back to n8n, which needs no Slack interactivity setup. The newer Approvals in Slack mode uses real Slack interactive buttons when you enable Capture Who Responded. It records the responder, can restrict who is allowed to approve and can update the message after the decision. For approvals that matter, use this mode.

Approvals in Slack needs interactivity enabled in your Slack app with the request URL n8n documents (ending in /webhook-waiting-slack), the app’s signing secret saved in the n8n credential, and the users:read and users:read.email scopes in addition to chat:write. Your n8n instance must be reachable over public HTTPS. Slack limits chat.postMessage to about one message per second per channel, which matters only if you send many approvals at once.

The workflow below has three outcomes for every request: approved, declined or expired. Nothing reaches the action node unless a permitted reviewer explicitly approved that request.

1. Trigger. The event that needs a decision, for example a refund request, a discount above a threshold or an AI agent’s proposed CRM update.
2. Prepare the request. A Set or Code node creates a request ID, a short summary, the exact change to be made and the requester. Write the request to a log (a database table, n8n Data Table or sheet) with status pending.
3. Ask the primary approver. Slack Send and Wait for Response to the approver’s direct message or a private channel, with Limit Wait Time enabled.
4. Route the answer. A Switch node with three rules: {{ $json.data.approved === true }} to the action path, {{ $json.data.approved === false }} to the declined path, and everything else to escalation.
5. Escalate once. A second Send and Wait for Response to a backup approver or a small approvals channel, with its own time limit and a message that says the first approver did not respond.
6. Route again. The same three rules. This time, “everything else” goes to expired: notify the requester and take no action.
7. Act and record. Before the action, re-read the request from the log and continue only if it is still pending. Mark it approved, perform the action, then store the result and the responder.

The third Switch rule is deliberate. A missing or unexpected value must never be treated as approval. Escalation exists for “no decision yet”, not for “declined”: if the primary approver says no, the request ends.

Limit Wait Time on the Slack node accepts either After Time Interval (an amount and a unit) or At Specified Time. The Wait node documentation explains the same idea for webhook and form waits: when the limit is reached, the workflow resumes.

n8n’s documentation does not state exactly what the Slack node outputs when its limit is reached. That is why the routing above sends anything that is not an explicit true or false to escalation. Before relying on it, run the timeout case in your own instance and look at the node output. One community report describes an execution that stopped with no output when a wait limit was set, so confirm that your execution reaches the escalation branch rather than ending.

How long to wait depends on the decision. n8n’s own human oversight playbook suggests hours for operational approvals and about a day for strategic ones, with an explicit timeout route. Set the limit from the cost of the delay, not from what feels polite.

With Approvals in Slack, Restrict Who Can Approve limits the decision to named users. Someone else who clicks gets a private notice (the Unauthorized Reply text) and the workflow keeps waiting. The output includes the responder’s Slack ID, name and email, which belongs in your decision log.

Restricting approvers does not restrict who can read the message. Anyone in the channel sees the request. Send sensitive approvals, such as refunds with customer details or access changes, to a direct message or a private channel, and keep the message to the information the approver needs.

Use the backup approver deliberately. It should be a person or a small group with the authority to make the same decision, not the whole team channel. If no one is available, expiry is a safer outcome than an approval nobody owns.

A request can be answered twice: a link button clicked again, a reviewer approving in the escalation message after the backup already declined, or a retried execution. The Approvals in Slack After Decision setting can show the outcome and remove the buttons, which removes the most common cause. It does not protect the action itself.

Bind every decision to the request ID and to the exact change that was shown. Before the action runs, re-read the request and continue only if it is still pending and the change is unchanged. If the action calls an external system, give it a stable idempotency key such as the request ID so a retry is recognised. Our n8n human approval lab tests these rules in 13 cases, and the webhook recovery lab tests duplicate callbacks and recovery after restarts with durable state. Both labs use webhooks rather than Slack, so they show the pattern, not this Slack configuration.

For each request, log the request ID, summary, requested change, approver asked, responder, decision, decision time, escalation flag and final status. That log answers “who approved this?” without searching Slack history.

The Wait node documentation says waits of 65 seconds or more are saved to the database rather than held in memory. It does not describe behaviour across every restart or upgrade, and community threads mention lost resume links when executions are retried or duplicated. If your approvals can wait for hours, test a restart of your n8n instance while a request is waiting and confirm the decision still resumes the right execution.

Also check your instance’s execution timeout settings so a long approval is not cut off by a global limit, and make sure someone can see waiting executions. A daily report of requests still pending is a simple safety net.

Download the Slack approval acceptance checklist. Every row starts as not_run. Run it against a test Slack channel and a sandbox action before connecting a real system.

• Approve from the primary approver: one action, logged responder.
• Decline from the primary approver: no action, no escalation.
• No response from the primary approver: escalation message sent once.
• No response from the backup: expired, requester notified, no action.
• Click by someone not allowed to approve: refused, still waiting.
• Second click after a decision: no second action.
• Request changed after it was sent: old approval not applied.
• n8n restarted while waiting: decision still resumes the right execution.
• Slack message fails to send: request marked as failed, someone notified.

If you want this built and tested against your own tools, our n8n automation service covers approval workflows, logging and handover.