ReferenceCampaigns
Execution states
An execution is one run of one campaign’s graph for one person, and it is always in one of five states: running, waiting for a reply, waiting out a delay, completed, or failed. A running execution walks the graph node by node until something parks it or ends it. Completed and failed are terminal — an execution never restarts, though a later event can start a new one.
The canvas execution panel does not print these five names. It shows whether a run is active, the node it sits on, the path it took, and an error message when there is one; the names below describe what those fields mean together.
Summary
Section titled “Summary”| State | What the execution is doing | Moves to, on what |
|---|---|---|
| Running | Walking the graph, executing each node it reaches | Waiting, Completed, or Failed — whichever the next node produces |
| Waiting for a reply | Parked on a condition whose wait_for_reply is on | Running on a reply; Failed after 7 days of silence |
| Waiting out a delay | Parked on a delay node with a scheduled resume | Running when the wait elapses; Completed if a reply cancels it; Failed if the resume never runs |
| Completed | Finished. No further nodes will run | Terminal |
| Failed | Stopped with an error recorded against it | Terminal |
State diagram
Section titled “State diagram”Running
Section titled “Running”- Active: yes
- Recorded: the node it is currently on, and every node it has already passed through
- Ends on: a
stopnode, an output with nothing connected downstream, or a revisited node
A running execution moves through the graph in one pass: the trigger, then each connected node in turn. Action nodes send their DM, publish their comment, or change the contact’s tags and hand control onward. Nothing is scheduled — a run pauses only at a delay node or at a condition that waits for a reply.
An action that raises an error stops the run advancing without ending it. The execution stays active with the error recorded against that node, which is why the panel can show an active run that is going nowhere; a sweep closes it as failed later.
Revisiting a node ends the run and records a cycle error naming that node. Every node in a graph runs at most once per execution.
Waiting for a reply
Section titled “Waiting for a reply”- Active: yes
- Recorded: a “waiting for reply” entry against the
conditionnode it parked on - Survives: 7 days without a reply
A condition with wait_for_reply turned on parks the execution instead of evaluating immediately. The person’s next DM, comment reply on the same thread, or button click wakes it up, and the text of that reply is what the condition matches: Match sends the run down the first output, No Match down the second.
An execution that waits 7 days without a reply is closed as failed, with a message saying the person never replied. That applies to test executions as well — a test run parked at a waiting condition has no real reply coming and expires the same way.
Waiting out a delay
Section titled “Waiting out a delay”- Active: yes
- Recorded: a “scheduled delay” entry naming the wait in seconds
- Survives: the whole scheduled wait; a resume more than an hour overdue is failed instead
A delay node schedules a resume and stops advancing. The configured delay_seconds is clamped to between 1 second and 31,536,000 seconds (365 days); a value outside that range is clipped without an error.
A delay whose only_if_no_reply is on checks for a reply when the wait elapses. If the person replied at any point during the wait, the execution completes instead of continuing down the branch.
A resume that never arrives is caught by an hourly sweep once its due time is more than an hour past, and the execution is closed as failed.
Completed
Section titled “Completed”- Active: no
- Recorded: a completion time and the full path of nodes the run passed through
- Error message: none
An execution completes when it reaches a stop node, when the output it takes has nothing connected to it, or when a reply cancels a delay that was set to continue only if no reply arrived. A run that ends at a stop node carries a “flow stopped” entry as its last recorded step, which distinguishes a deliberate ending from a branch that had nothing wired to it.
Completion is not a verdict on whether the campaign did what you wanted: an execution that matched no keyword and left through an unconnected No Match output is a completed execution.
Failed
Section titled “Failed”- Active: no
- Recorded: an error message and the node the run stopped on
- Retried: the scheduled resume after a delay, up to three times; nothing else
An execution fails in four ways: a node is revisited, an action node raises an error and the stalled run is swept up, a waiting condition passes 7 days without a reply, or a scheduled resume never runs.
A stalled run — active, with an error on its last visited node — is closed within an hour when it still has a scheduled step outstanding, and once it has been idle for 7 days when it does not. Until then the panel shows it as active, so an error message on an active run is the signal that the run is over in practice.
What a failure records
Section titled “What a failure records”| Recorded | Where you see it |
|---|---|
| The error text from the failed call — a rejected DM, a comment that no longer exists, a revoked page token | On the execution, and against the node that raised it in the path |
| The node the run stopped on | The current-node marker in the canvas overlay |
| The path taken up to that node | Visited-node highlighting on the graph version the run was pinned to |
| The reason a sweep closed the run | On the execution: no reply within 7 days, or a scheduled step that did not run |
Retries are narrow. A scheduled resume after a delay is attempted up to three times, with a widening gap that starts at five seconds, and the execution is marked failed after the third attempt. An action that fails while the run is walking the graph is not retried, and no execution is re-run from the start.
A person whose execution failed is not shut out of the campaign. The one-run-per-person rule counts only executions that are still running, so their next matching event starts a fresh one.
- Every execution is pinned to the graph version it started on. Saving the campaign mid-run leaves that run on its own version, and the panel replays it against the version it used.
- Test executions run the whole graph without calling Facebook or Instagram and without changing tags. A
delaynode ends a test run rather than scheduling it, recording the delay as skipped. - The panel lists the 20 most recent executions for the campaign, newest first, with test runs marked as tests, and does not update on its own — refresh it to see how far a run has got.
Related
Section titled “Related”- Trigger events — which events start an execution, and which are ignored.
- Test and debug campaigns — reading the execution panel when a campaign did not do what you expected.
- Node types — the configuration behind
wait_for_reply,delay_seconds, andonly_if_no_reply.