Skip to main content
A workflow is either Live or Paused.
  • Live workflows accept trigger events and queue runs when project usage requirements are satisfied.
  • Paused workflows reject newly created runs before execution.
New workflows start Paused so you can configure the trigger and graph before allowing events to execute actions.

​
Enable a workflow

1

Finish the trigger configuration

Open the trigger drawer, select any required account, and complete the trigger-specific settings.
2

Wait for the graph to save

Confirm the editor shows Saved. Enabling does not force a pending graph save to finish first.
3

Check integrations and billing

Confirm selected accounts are healthy. For billable triggers, confirm the project has run credits or active usage billing.
4

Set the workflow Live

Open the status menu at the top of the editor and choose Enable Workflow. The status changes to Live.
5

Send a new test event

Trigger the workflow and inspect its new run in Run History.

​
Pause a workflow

Open the Live status menu and choose Pause Workflow. The status changes to Paused. Pausing is immediate for runs created after the status update, but it is not a subscription teardown or queue purge.
Pausing does not cancel runs that are already Scheduled. Those delayed runs remain queued and can execute at their scheduled time. Cancel each Scheduled run from run history when it must not execute.

​
What happens to events while paused

External trigger subscriptions remain configured while the workflow is paused. When a trigger event tries to start the workflow:
  1. WorkflowDog creates a run record from the event.
  2. The eligibility check sees that the workflow is paused.
  3. The run is marked Failed with The workflow is paused.
  4. The event is not queued for later execution.
Enabling the workflow later does not replay these paused-event failures. The same rule applies to manually choosing Re-run while the workflow is paused: the new run fails the paused eligibility check.
Keeping the external subscription configured makes pause and resume fast and avoids repeatedly creating provider webhooks or watches. It also means run history can show failed paused events.

​
Pausing and scheduled work

A Schedule Workflow action reserves and queues its delayed run when the parent workflow executes. The destination workflow’s Live or Paused state is checked at that queueing moment. If the destination is Live when the run is scheduled and becomes Paused later, the existing Scheduled run is not checked again before execution. Cancel it explicitly if the pause should include already scheduled work.

​
Pausing and integrations

Pausing does not:
  • Disconnect integration accounts.
  • Revoke provider permissions.
  • Remove Gmail watches, Microsoft subscriptions, or other external event sources.
  • Clear trigger configuration.
Use Integrations to replace or disconnect an account. See External triggers for the subscription lifecycle.

​
Billing can still stop a Live workflow

Live means the workflow is allowed to run; it does not bypass project usage checks. A Live workflow can create a Failed run when:
  • The project has no run credits and no usage subscription.
  • The subscription exists but its payment state does not allow new usage.
Resolve the project issue under Usage and billing, then send a new event or manually re-run the saved payload.

​
When to pause

Pause a workflow when:
  • Editing actions that send messages or change external data.
  • Rotating an integration account.
  • Investigating repeated bad inputs.
  • Preventing new work while you cancel already Scheduled runs.
For a planned account migration, pause first, swap action usages, reconfigure the trigger, confirm the new account is healthy, and then enable the workflow.

​
Troubleshooting

Check whether it was already in Scheduled status before the pause. Pausing blocks newly queued work but does not cancel delayed runs that were already accepted.
The trigger subscription is still receiving events. This is expected while paused. Enable the workflow when ready, or reconfigure/disconnect the trigger source when you need events to stop at the provider.
Open the failure tooltip. Out-of-credit and invalid-payment failures are project billing problems, while a worker failure is an execution-system problem.
Confirm the workflow is Live and the project can accept billable runs. A manual re-run goes through the same pause and billing checks as a trigger event.