Skip to main content
Every time a workflow runs, it does so as an execution — a single run of the workflow with its own history of events, node results, and state. Two settings shape how executions behave: the workflow’s execution mode and the engine’s built-in lifecycle rules that decide when an execution is finished.

​
Execution mode

Open Settings in the left rail of the canvas. Under How triggers start runs, choose how events are grouped across runs. The two choices keep their older names, Multi instance and Single instance, as a small caption, so you can match them to the API and older docs.
Workflow settings with the choice of how triggers start runs
Best for: workflows that act like a persistent listener — one Gmail watcher, one webhook receiver, one scheduled poller.All events arrive inside the same running execution. Triggers route to the most recent running execution, so the history, variables, and dispatcher conversations accumulate in one place.Use one shared run when steps must share state across events. The settings recommend a run per event for most workflows.
Best for: workflows where each incoming event should be tracked separately — one execution per support ticket, per order, per inbound call.Triggers configured to start a new run spawn a fresh execution for every event. Each run is fully independent — its own history, its own variables, its own lifecycle.Use a run per event when you want isolated runs you can audit or reproduce individually.
The same settings popover has Runs at the same time (earlier called Concurrent sequences). Leave it empty for no limit; enter 1 to run them one after another.
The execution mode is a property of the workflow, not of an individual run. Switching modes affects how future triggers are routed; existing executions are unaffected.

​
Run buttons

The run controls sit in the editor header, next to the status pill. They depend on the mode and on whether the workflow is on: While the latest run of a run per event workflow is still going, the header also shows Stop run, which stops that run, the same as Stop run in Runs. A run with steps that can still receive events, such as a trigger or a webhook, keeps going until it is stopped (see Auto-stop). The bottom of the left rail has the same controls as icon buttons. There, a run per event workflow that is on also shows Turn off. Click the status pill (On, Off, Paused or Needs attention) to see how the workflow starts and its last run. For a run per event workflow it also has Turn on / Turn off. Run and Run now open the Run workflow dialog. It shows an estimate of what the run costs and your credit balance. For a one shared run workflow it also says that starting the run turns the workflow on. Open More options to set Run name (optional), which is shown in the run list so you can find the run later. If the workflow has problems, Turn on and Run first show a Before turning on (N) (or Before running) check listing them, with Turn on anyway (or Run anyway). See Version history for rolling back a change that caused them.

​
How an execution ends

An execution moves through one of four terminal states:

​
Auto-stop

The engine watches each execution and stops it automatically when no more work is possible. This keeps the execution list clean and frees up resources — you don’t have to stop every finished run. An execution auto-stops when all of the following are true:
  • Every branch of the workflow has finished running.
  • The graph has no node types that can receive new events later — no triggers, webhooks, scheduled events, portal entry points, dispatchers, or Chat & Voice Agent steps.
  • No queued jobs remain for this execution.
The final status is inferred from what happened during the run:
  • completed — every node that ran succeeded.
  • failed — one or more nodes failed.
Auto-stop runs the same cleanup as manual stop. Pipedream triggers, scheduled cron jobs, channel pollers, and active dispatcher conversations are all released before the execution is marked terminal.

​
Manual stop

In a one shared run (Single instance) workflow, click Stop and turn off in the header to halt the running execution and turn the workflow off. In a run per event (Multi instance) workflow, click Stop run in the header while the latest run is going, or open Runs and click Stop run on any run. Use Turn off in the status pill to switch the workflow off. The execution is marked stopped and the engine performs the same cleanup as auto-stop.
Stopping an execution does not undo the work that already happened — emails that were sent stay sent, records that were written stay written. Stop ends the run; it does not roll it back.

​
Viewing executions

Click Runs in the left rail to open the execution history and live event log. Each row is one run of the workflow, with its status, start time, and duration.
Execution History icon in the toolbar and the resulting executions list panel
Pick an execution to drill into its event timeline — every node that started, finished, or failed, in the order it happened. Filter with the chips All, Running, Failed, Succeeded and Stopped, or use Search runs to find a specific run. Click a step on the run canvas to open the same step details as the timeline. Opening a failed run centers the failed step, which shows a one-line plain summary with Technical details collapsed beneath. Explain this error opens the Concierge with a draft that names the step and the error summary; you send it yourself. Fix in step leaves the run view and opens that step so you can change it. The run details header shows Cost: N cr, the credits the run used (with so far while it is running). Step details show a step’s own credits when they are known. Nothing is shown when there was no charge. The run details show how and by whom the run started, and its inputs (secret variables are masked). Copy link gives a link that opens that run. Run again starts a new run with the same inputs; in a one shared run workflow it asks first, because the current run stops.
Events panel for a single execution showing live node-by-node activity

​
Choosing between modes

  • Your workflow reacts to a stream of events that don’t need to be tracked separately (“notify me whenever a new lead comes in”).
  • You want a single timeline of activity across all events.
  • You want lower overhead — only one execution is ever active.
  • Each incoming event represents an independent unit of work (“process this order from start to finish”).
  • You need isolated history per event for auditing or debugging.
  • Different events should be able to fail independently without affecting each other.

​
Next steps

Run a workflow

Walk through starting a run end-to-end.

Trigger nodes

See which trigger types can spawn or feed an execution.