Skip to main content
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.Only CRMs you’ve connected appear as options. Connect yours first in Integrations.
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.
  • 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, 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:

Agent

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.

CRM Sync

Pushes data back to your CRM: create notes and tasks, update fields. Keeps your system of record current with what the workflow decided.

Send Email

Sends an email with variable interpolation for recipients, subject, and body — an internal notification or a templated send, personalized from the run’s context.

End

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.

​
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.