Track complaint SLAs and escalation alerts with Gmail and data tables

Quick overview Accept complaint metadata, assign an owner, and track a separately supplied response deadline. Authenticated owner actions acknowledge or close cases. A 15-minute sweep escalates unacknowledged ownership and sends internal Gmail alerts, with durable records and manual reconciliation for uncertain sends. How it works 1. An authenticated webhook validates a strict metadata contract. Stable tenant/source identity detects exact sequential replays and conflicting retries. The case is persisted before the webhook confirms success. 2. Ownership escalates from owner to lead to manager when the assigned role does not acknowledge within the configured interval, two elapsed hours by default. 3. A separate supplied response deadline produces 72-hour, 24-hour, breach and daily overdue alerts. Acknowledging ownership does not stop deadline alerts. Missing deadlines produce a review alert. 4. The currently assigned role can acknowledge or close a case through a second authenticated webhook. Closure requires a resolution reference and stops future alerts. 5. Before internal Gmail delivery, the workflow verifies case state and a durable alert intent. A provider message ID is required for success. Uncertain outcomes surface an error and require reconciliation before any retry. Setup 1. Import inactive. In Workflow settings, confirm UTC, execution logic v1, and Do not save for failed, successful and manual executions; editor imports can retain destination settings. Create ComplaintCases and ComplaintAlerts with the schemas below, then select them in every Data Table node. 2. Configure COMPLAINTINTAKETOKEN and distinct COMPLAINTOWNERTOKEN, COMPLAINTLEADTOKEN and COMPLAINTMANAGERTOKEN in n8n Variables. Each token must be 24–256 characters, and all role tokens must differ from the intake token. 3. Configure COMPLAINTOWNEREMAIL, COMPLAINTLEADEMAIL and COMPLAINTMANAGEREMAIL with internal inboxes, then connect Gmail OAuth. Optional COMPLAINTACKSLAHOURS accepts integer 1–168 and defaults to 2. Self-hosted Code nodes require the crypto built-in. 4. Use the exact intake and owner-action examples below. Keep original complaint text, customer addresses and attachments in your source system. Provide explicit timestamp offsets and a reviewed deadline with policy reference, or null plus an empty policy reference for review. 5. Serialize intake, owner actions and sweeps for this lane, or replace Data Tables with transactional storage before concurrent use. Test synthetic intake, exact replay, acknowledgement, overdue acknowledged cases, closure and ambiguous delivery handling before activation. Requirements - n8n Variables, Data Tables, Gmail OAuth and a trusted source-system caller. One configured team owns the entire lane. Deadlines come from your policy process; the template does not calculate statutory periods or decide complaints. Customization - Adjust internal recipients, ownership SLA hours and sweep frequency. Connect the metadata contract to your existing complaint source and reviewed deadline policy. Additional info Variables | Variable | Purpose | |---|---| | COMPLAINTINTAKETOKEN | Bearer token for the source-system intake lane | | COMPLAINTOWNERTOKEN | Bearer token for the owner role | | COMPLAINTLEADTOKEN | Bearer token for the lead role | | COMPLAINTMANAGERTOKEN | Bearer token for the manager role | | COMPLAINTOWNEREMAIL | Internal inbox for initial owner alerts | | COMPLAINTLEADEMAIL | Internal inbox for first escalation | | COMPLAINTMANAGEREMAIL | Internal inbox for final escalation | | COMPLAINTACKSLAHOURS | Optional integer 1–168; default 2 elapsed hours | Each token must be 24–256 characters. All three owner-role tokens must be configured, distinct from each other and distinct from the intake token. Use generated secrets, not the illustrative values in tests. All webhooks require exactly one Authorization: Bearer <token header. Owner identity is derived from the matched server-side role token; a caller-supplied actor field gr