Skip to main content
Once a workflow is built and validated, you activate it. From then on, every trigger creates a run — one account walking the graph — and every run leaves a full record of what happened at each step.

​
Activating a workflow

Activation is an admin action, done from the Workflows page or the workflow editor. Draft workflows never respond to triggers; only active ones do.
One active CRM workflow at a time. CRM-triggered workflows that create accounts are exclusive per organization — activating one automatically deactivates whichever held the slot before, so two workflows can never race to create the same account from the same CRM event. The Workflows page shows the current holder as your active onboarding workflow.
Workflows scoped to existing accounts, and all manual and scheduled workflows, don’t compete for that slot — several can be active at once.
Activating a CRM workflow means it starts responding to real CRM events immediately. Double-check the trigger’s pipeline and stage before you flip it on.

​
Runs

Each run tracks one account through the workflow: which node it’s on, the data it has collected, and how it ends. A run is in one of these states: Transient node errors don’t fail a run immediately — the engine retries the node automatically with backoff before giving up. And a paused run is not a stuck run: holding for days at a Wait node or weeks at a human gate is normal, durable behavior. The Workflows page’s run history lists recent runs across all workflows — which account, which workflow, current state, and when it started. Click any run to open its detail view.

​
The run detail view

The run detail view shows the workflow canvas in read-only mode with the run’s progress laid over it:
  • Node status — which nodes completed, which one the run is holding at, and where an error occurred.
  • The execution log — a step-by-step record of what each node did, in order.
  • Pending human items — any gate the run is waiting on, and who it’s waiting for.
Every member of your org can open a run’s detail view — not just admins. When a failure notice or a decision lands with a teammate, they can follow it straight to the run and see the whole story. Admin permissions gate only the management actions on the run, like cancelling it or editing the workflow.
Cancelling a run (admin-only) stops it where it stands and withdraws any pending human items. The account keeps whatever state the run had already applied.

​
Human gates in practice

When a run reaches a Decision node, it pauses and the decision goes to the person the node names:
1

The item lands

Internal decisions appear in the assignee’s Inbox with the account and the context the node was configured to show. External approvers get an email with a no-login token link instead — see External approvals.
2

A person decides

Approve, reject, or — in review mode — edit and send along. Approval items are decided individually: the Inbox’s bulk actions never clear them, and there is no batch-approve. Each gate gets an explicit human decision.
3

The run resumes

The decision releases the run down the matching path immediately. If the node has a timeout configured, an undecided gate eventually takes its timeout action instead — auto-approve, auto-reject, or escalate to a named person.

​
Where failures surface

A failed run does two things:
  1. The run is marked Failed, with the error recorded on the failing node in the run detail view.
  2. A quiet, dismissible notice appears in the Inbox, deep-linking to the failed run. Runs you launched manually notify you; CRM-triggered and scheduled runs notify the org team inbox, so system-triggered failures are never dropped on the floor.
The notice is informational — there’s no in-place retry to perform on it. Read the run detail to find the cause (a disconnected integration, a missing CRM field, a bad variable reference are the usual suspects), fix the root cause, and dismiss the notice. Re-running is a fresh trigger: run a manual workflow again, or let the next CRM event or scheduled tick start a new run.

​
Keeping workflows healthy

  • Watch the run history after activating — the first few real runs tell you whether the trigger and branches match reality.
  • Clear gates promptly. A run waiting on a decision is doing its job, but an account is standing still while it waits.
  • Investigate repeat failures. The same error on the same node across runs points at configuration — a variable that’s sometimes absent, an integration that needs reconnecting in Integrations.

Building workflows

Adjust triggers, branches, and gates as you learn from real runs.

Inbox

Where decisions and failure notices land for your team.