> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thread.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Running workflows
> Activate a workflow, follow its runs in the run detail view, clear human gates from the Inbox, and see where failures surface.
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:
| State | Meaning |
| -------------------- | ------------------------------------------------------------ |
| **Running** | Executing nodes now |
| **Paused / Waiting** | Holding at a human gate, a Wait node, or a long-running step |
| **Completed** | Reached an End node |
| **Failed** | A node error stopped the run |
| **Cancelled** | Stopped by an admin |
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:
Internal decisions appear in the assignee's [Inbox](/inbox/overview) 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](/inbox/external-approvals).
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.
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](/inbox/overview), 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](/integrations/overview).
Adjust triggers, branches, and gates as you learn from real runs.
Where decisions and failure notices land for your team.