> ## 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. # Building workflows > Design a workflow on the canvas: pick a trigger, branch on account facts, add human gates and waits, and wire in action nodes. A workflow is built on a visual canvas: you add nodes, connect them, and configure each one. Every workflow starts at a **Start** node (the trigger), flows through routing and action nodes, and finishes at one or more **End** nodes. Building workflows requires the **org admin** role. Go to **Workflows** in the main navigation and create one under the section matching its trigger — onboarding (CRM), manual, or scheduled. ## Triggers The Start node defines when a run begins and which account it runs for. The workflow fires when a record in your connected CRM reaches a stage you choose: * **HubSpot** — a deal reaches a stage in a pipeline you select. * **Salesforce** — an opportunity reaches a stage you select (optionally filtered to one record type). * **Notion** — a database entry's status property changes to a value you select. CRM triggers also carry an **account scope**: whether the workflow creates a new Thread account from the CRM record, runs against an account that already exists, or does either. Scope matters at activation time — see [Running workflows](/workflows/running-workflows). Only CRMs you've connected appear as options. Connect yours first in [Integrations](/integrations/overview). You launch the run yourself from the Workflows page with a **Run** button, choosing which account it runs against. A manual workflow can also declare input fields — values you supply at launch that flow into the run for branches and actions to use. The workflow runs on a cron cadence in a timezone you choose, against accounts matching a filter — lifecycle stage, owner, ARR range. Useful for recurring sweeps that apply the same routing logic on a schedule. ## Branching on facts Two nodes read the run's context — account fields, the CRM snapshot, and anything upstream nodes produced — and pick a path: * **If/Then** — a yes/no test on one fact (`ARR greater than…`, `segment equals…`, `field is present`). Two outputs: Yes and No. * **Route By** — matches one value against several cases (Enterprise / Mid-Market / SMB, region, product tier), with an optional default path. One output per case. Configure values with the variable picker rather than typing paths by hand — it shows exactly which fields the run will carry, and typos in variable references are a common validation failure. ## Human gates The **Decision** node pauses the run until a person decides. Nothing downstream executes until they do. * **Who decides:** a specific teammate, any org admin, or an **external approver** — someone outside Thread, reached by email with a no-login token link. External links expire (72 hours by default). See [External approvals](/inbox/external-approvals). * **What they see:** the title, description, and the context fields you choose to show, alongside the account. * **Two modes:** *decision* gives the approver Approve/Reject buttons and the node two output paths; *review* gives a single output path — the approver reviews (and can edit) what's about to happen, then sends it along. * **Timeouts:** optionally, after a number of hours with no decision, the node can auto-approve, auto-reject, or escalate to a named person. Human gates are decided **one at a time**. Internal decisions land in the [Inbox](/inbox/overview), and approval items there can't be bulk-cleared or batch-approved — each one takes an explicit decision. Design your branches so a gate only fires when a human judgment is genuinely needed. ## Waits The **Wait** node pauses the run for a duration — minutes, hours, or days, up to **30 days** per node, measured in calendar time. Combined with human gates, this is what makes workflows durable: a run can hold its state for weeks, then continue exactly where it left off. No polling, no re-triggering. ## Action nodes Action nodes execute automatically when the run reaches them: Runs an AI agent as a step in the flow — to gather data from connected systems, enrich the account, or perform a multi-step task. What the agent produces lands in the run's context, so downstream branches can route on it. Pushes data back to your CRM: create notes and tasks, update fields. Keeps your system of record current with what the workflow decided. Sends an email with variable interpolation for recipients, subject, and body — an internal notification or a templated send, personalized from the run's context. Marks the run complete. A workflow can have several End nodes, one per outcome, which keeps run history legible. ## Validate, then activate Thread validates the graph before it will activate: every node connected, every path reaching an End node, required configuration filled in, and variable references pointing at data that will actually exist. Fix what it flags, save, and activate from the workflow editor. Activation behavior — including the one-active-CRM-workflow rule — is covered in [Running workflows](/workflows/running-workflows). ## Building well * **Start linear.** Get one path working end to end, then add branches. * **Name nodes for what they decide**, not what they are — "Enterprise?" beats "Condition 2". * **Branch early.** Read the facts near the top so each path stays simple. * **Gate deliberately.** Every Decision node is a human interruption; use them where judgment matters and let facts route everything else.