Long-running workflows in n8n: let the job hold the state, not the execution.
A job that takes days or weeks has to keep its state somewhere between executions. This guide covers what n8n gives you for waiting, where a waiting execution runs out of road, and a pattern that keeps every execution short: one record per job, one state at a time, and a trigger when it moves.
n8n-nodes-inistate is a verified community node, installable on n8n Cloud and self-hosted.
Two things people mean by long-running
Workflow state management in n8n covers two different problems, and they want different tools.
A long-running execution
One run of one workflow that has to wait: for a timer, a callback from an API, a person’s reply. The state is the execution’s own, and n8n’s job is to park it cheaply and bring it back. The Wait node is built for exactly this.
A long-running job
A piece of work that lasts days or weeks and passes through several hands: a service visit, a claim, a client onboarding. It has a status someone asks about, an owner, steps that happen in an order nobody fixed in advance, and a history someone will need. Its state belongs to the job, not to any one execution.
It is a long-running job, not a long wait, when:
- the work pauses more than once, and not always in the same order;
- more than one person or system acts on it before it is done;
- somebody has to be able to change who does the next step;
- a mistake halfway has to be corrected, not restarted;
- the customer, or the client’s team, asks where it stands;
- in a month, someone will ask what happened and who did it.
One of these is a branch. Three of them are a system, and it is worth deciding where its state lives before the second client.
How n8n waits today
n8n gives you good ways to pause and resume. Use them where they fit; the pattern later in this guide sits alongside them, not instead of them.
The Wait node
Pauses the execution until an interval has passed, a set time, a webhook call or a form submission. n8n offloads the paused execution to its database, so nothing sits in memory, and the documentation sets no ceiling on how long it can wait.
- Keep in mind One execution per waiting job. Whatever happens next has to arrive at this execution’s resume URL, and a partial run in the editor changes that URL.
Send and wait for response
Slack, Gmail, Telegram, Microsoft Teams and other nodes can send a message and pause until someone approves, declines or fills in a form, with an optional time limit. An AI Agent’s tool call can be held for review the same way.
- Keep in mind The answer returns to the execution that asked. If the person changes, the message has already gone.
A resume-URL registry
n8n’s template gallery has a state-management system for long-running workflows: a registry of paused executions and their resume URLs, kept in workflow static data, which a second workflow consults when an outside event arrives.
- Keep in mind You now maintain a small routing system, and static data is saved only when a production execution succeeds.
A database and a schedule
Write the job to Postgres, Airtable or a data table with a status column. A Schedule Trigger polls for rows that are due, and webhooks update them.
- Keep in mind The status column has no rules of its own. Which change is allowed, by whom, with what information, is decided again in every workflow that touches the table.
Summarised from the n8n documentation in September 2026: the Wait node, managing execution data and workflow static data; the registry pattern is a template in n8n’s own gallery.
Where a waiting execution runs out of road
Each of these is fine once. They arrive together around the tenth job.
No list of jobs
Forty jobs in flight are forty waiting executions, filed under the workflow and the time they started. Nothing shows them by customer, technician or step.
One way forward
The resume URL went to one place. A swapped technician, a rescheduled visit or a cancellation each needs its own branch, and each branch has to find the right paused execution.
Corrections after the fact
Someone marks the wrong job complete. The execution has moved on, so undoing it is a compensating path you write, not a step someone takes.
Nowhere for the client to look
An execution has no screen. The client’s team asks in WhatsApp, or you build them a portal and keep it running.
History that thins out
n8n prunes finished executions by default. The waiting one is kept, but the runs before and after it go, and in month two someone asks what happened on job 118.
The same build, next client
The tables, the resume routing, the status messages and the portal are a project of their own, and the next client needs the same set.
State management with a workflow, not a status column
Give the job a record with one current state, and let each n8n workflow do one part. Every wait is a state on the record. Every resume is a trigger.
Does its part, then ends
Books the job, sends the confirmation, raises the invoice. When it needs the record to move, it performs an activity through the Inistate node. Seconds later, it is finished.
Changes state and waits
The job sits in Scheduled, In Progress or Completed, with an owner and a due date. People act on it from the web or a phone, through the activities that state permits and the form each one requires.
Starts the next workflow
Fires when the record is created or updated, when an activity is performed, or when it enters or leaves a state, whoever moved it, and hands the next workflow the whole record.
↺ And back to the first, as many times as the job needs.
State → Activity (Form) → State. The same contract whether a person, an AI agent or an n8n workflow performs the activity. The n8n state management page covers the contract itself; this page is the build.
Build it: a field service job, from booking to invoice
Four short n8n workflows, one record per job, and the technician on a phone. The states, activities and fields are the Field Service Job template’s own.
-
Inistate
Start from the Field Service Job template
Create a workspace and pick Field Service Job. A job records Customer, Site Address, Job Type, Technician and Scheduled Date, and moves Scheduled → In Progress → Completed → Invoiced, with Cancelled to one side. Clock In, Complete Job (Parts Used, Hours, Photos), Send Invoice (Invoice Amount) and Cancel are its activities. Rename or add what your service business needs; the node reads the module as it is.
-
n8n
Workflow 1: book the job
Start from wherever requests arrive: an n8n Form, a Webhook from your website, a Gmail or WhatsApp trigger, your CRM. Map the request onto a job, and end.
- Inistate node Resource: Entry. Operation: Create. Workspace and Module: Field Service Job.
- Fields Loaded from the module’s create form. Map Customer, Site Address, Job Type, Scheduled Date and Technician from the request.
- Output The new record, including its document ID.
The job is Scheduled. Nothing is waiting.
-
n8n
Workflow 2: confirm with the customer
Messaging is what n8n is good at, so the confirmation stays in n8n. The trigger registers a hook in Inistate when you activate the workflow and removes it when you deactivate it; as with any webhook, your n8n has to be reachable from the internet.
- Inistate Trigger Trigger On: Entry Created. Module: Field Service Job.
- Then A WhatsApp, SMS or email node, with
{{ $json.data['Scheduled Date'] }}and{{ $json.data['Technician'] }}in the message. - Optional A second workflow on Entry Updated, for a reschedule notice.
-
People, in the Inistate app
The visit: Clock In and Complete Job
On the day, the technician opens the job on the phone and performs Clock In; the job is In Progress. When the work is done, Complete Job asks for Parts Used, Hours and Photos, and the job is Completed.
Between the booking and this moment, a day or a fortnight may pass, and no execution is open anywhere. If the customer reschedules, the office changes Scheduled Date on the record. If a technician is swapped, the job is reassigned. Neither touches n8n.
-
n8n
Workflow 3: raise the invoice
The trigger hands this workflow the whole record: Hours and Parts Used under
data, the job’s document ID underheader.documentId.- Inistate Trigger Trigger On: Activity Performed. Activity: Complete Job.
- Accounting Your Xero or QuickBooks node, or an HTTP Request, creates the invoice from Hours and Parts Used, with the document ID as its reference.
- Inistate node Operation: Perform Activity. Document ID:
{{ $json.header.documentId }}. Activity: Send Invoice. Invoice Amount: from the invoice.
The job is Invoiced, with the amount on its history.
-
n8n
Workflow 4: record the payment
The template ends at Invoiced. Add a Paid state and a Record Payment activity to the module, and the node lists them the next time you open it. When the accounting tool’s payment webhook arrives, its reference is the job’s document ID.
- Trigger The payment webhook from Xero, QuickBooks or Stripe.
- Inistate node Operation: Perform Activity. Document ID: the payment’s reference. Activity: Record Payment.
The job is Paid. Four workflows ran; none waited.
-
Inistate
Reminders and exceptions, without an execution
A job still Scheduled the morning after its date, or Completed for three days without an invoice, gets a reminder or an alert from Inistate’s built-in automations; nothing in n8n polls for it. Cancel is an activity on the record, so a cancelled job leaves Scheduled through the front door, and a State Changed trigger (To State: Cancelled) can tell the customer.
What workflow 3 receives, abridged
{
"header": {
"documentId": "FSJ00042",
"title": "Aircon service, Tan residence",
"state": "Completed",
"activityId": "…",
"assignees": ["lim@example.com"],
"due": null
},
"data": {
"Customer": "Mrs Tan",
"Site Address": "12 Jalan Damai",
"Job Type": "Service Visit",
"Technician": "Lim",
"Hours": 2.5,
"Parts Used": "Capacitor 35uF",
"Photos": […]
}
}
The document ID and the fields are examples. Every step a person took, every activity a workflow performed and every state the job passed through is on the record’s history, in order, with who did it and what they entered. The executions in n8n can be pruned; the job keeps its own story.
A waiting execution, or a record and short executions
The same job, held two ways.
| Question | Waiting execution | Record and short executions |
|---|---|---|
| Where the job’s state lives | In the paused execution’s data | On the record, as its current state |
| What waits | The execution | The record, in a state, with an owner |
| Everything in flight | The executions list, per workflow | The module’s list, by state, owner and due date, on web and phone |
| The next step is decided by | The branch the execution is on | The state: the activities it permits, read when someone acts |
| Changing the technician midway | The message has gone out; usually a new branch | Reassign, from the app or from n8n; the workflows stay as they are |
| A correction | A compensating path | An activity, or a state change, on the record’s history |
| The client’s view | Build one | The Inistate web and mobile app, guests included |
| What remains a month later | Execution logs, pruned by default | The record’s history: who acted, with which input, from which state |
| Best for | One pause with one way forward | Work with several handoffs over days or weeks |
When the Wait node is the right answer
Use the Wait node when the pause is one step with one way forward: a delay before a retry, a callback from an API that always answers, a single confirmation from a known person, a form filled in once. Nobody will ask where it stands, and nobody will need to change it midway. Reach for a record when the wait is a stage in someone’s work: several pauses, more than one person, an order nobody fixed in advance, and a status that people ask about.
Many automations. One governed workflow.
Long-running workflows in n8n, answered
The questions that come up once a workflow has to outlast its execution.
How long can an n8n workflow wait?
The Wait node can pause until an interval has passed, a set time, a webhook call or a form submission, and n8n offloads the paused execution to its database rather than holding it in memory; the documentation gives no ceiling. Send and Wait for Response adds a Limit Wait Time option that resumes the execution when the limit passes. The practical limit is operational rather than technical: while a job is a waiting execution, nothing but that execution knows where the job stands.
How do I resume an n8n workflow from an external event days later?
The Wait node’s On Webhook Call mode gives each execution a resume URL in $execution.resumeUrl. Send it to the system or person that will answer, and store it if the answer may come from somewhere else; a partial execution changes the URL, so the node that sends it must run in the same execution as the Wait node. n8n’s template gallery has a state-management system that keeps a registry of paused executions and their resume URLs in workflow static data. In the record pattern there is nothing to resume: the outside event performs an activity on the record, or updates it, and the Inistate Trigger starts a fresh execution.
How do I see every job that is in progress?
In n8n, the executions list shows waiting executions per workflow. It does not group them by customer, technician or step. With the record pattern, the module’s list is that view: filter by state, owner or due date, on the web or on a phone, and open a job to read its history.
What does the Inistate Trigger send to n8n?
The webhook body, as it arrives: a header with the record’s document ID, title, current state, assignees, due date and the activity that fired it, and data with the record’s fields by name. So a Perform Activity node later in the workflow can take {{ $json.header.documentId }} as its Document ID, and a message node can read {{ $json.data['Scheduled Date'] }}.
Can I change the process while jobs are in flight?
Yes. A record keeps the state it is in, and the activities it may take are read from the workflow at the moment someone acts, so a new state or activity applies to the records that reach it from then on. The n8n workflows around it change only if you want a new trigger or a new step.
Do I need a database to keep state between n8n executions?
Only if the state is yours to keep. For a cursor or a counter, workflow static data or a data table is enough. For a job with an owner, a next step and a history, the database is where the work starts: the status column needs rules, forms, a screen and a log around it. Inistate is that layer, with the node as the connection. See n8n state management for how the options compare.
Is this the same as durable execution?
No. Durable execution tools such as Temporal resume a program after a crash or a restart, so code itself can wait for days. That is about the execution. Inistate holds the state of the work, which people, AI agents and any number of executions act on, and n8n keeps running the executions. The two answer different questions.
Does this replace the Wait node?
No. Use the Wait node for one pause with one way forward: a delay before a retry, a callback from an API, a single confirmation. Use a record when the wait is a stage in a job that people work on: several pauses, more than one person, an order nobody fixed in advance, and someone asking where it stands.
Put one long-running job behind n8n
Free forever for small teams. Start from the Field Service Job template, install the node, and let the record do the waiting.