Skip to main content
An Attio workflow is an event-driven automation inside your CRM. A trigger starts a run, and a chain of blocks does the work. “Event-driven” means the workflow waits for something to happen, then acts. The shape is always the same: when something happens, do these things. A deal moves stage, so the workflow notifies a channel. A form submits, so it creates the lead, fills in its details, and routes it. Every Monday morning, it sweeps the pipeline for stale deals and assigns follow-ups. For a go-to-market (GTM) engineer, workflows connect your CRM to the rest of your tools. They turn manual chores into rules the system runs for you. That covers lead routing, pipeline hygiene, sequence enrollment, and AI enrichment. You build them on a visual canvas. You can also describe the outcome in plain language and let Ask Attio assemble the blocks for you. The underlying structure is the same either way. Learning that structure is most of what it takes to master the engine. Once you can read a workflow as one trigger plus an ordered chain of blocks passing data downstream, every recipe in this handbook becomes easy to follow. This page gives you that mental model. It shows you the smallest workflow that does real work, and it marks the boundaries where a workflow is the wrong tool.

​
Reading the trigger-and-blocks model

Every workflow is exactly one trigger followed by one or more blocks. You wire them together on a canvas in the order they run. The trigger answers one question: when does this run? The blocks answer the next one: and then what? A trigger is the single event that starts a run. It might be a record created, an attribute changing value, a schedule firing, a webhook arriving, or a person running a command from a record. You pick one trigger per workflow. See Choosing the right trigger for how to match an event to an intent. A block is one operation. It might Update record, Create task, post to Slack, send an HTTP request, or run an AI agent. You assemble blocks from the block reference library. Here is the smallest workflow that earns its keep. It is a one-block run that stamps an owner onto a new lead. When a new person record appears, the run fires and writes owner = Priya Sharma onto that record. That is a complete, publishable workflow. It has one trigger, one block, and one observable change in the CRM.

​
Branching the path with conditions

Real workflows rarely run in a straight line. Connections between blocks define the order. Condition blocks let one trigger fan out to different outcomes. The If block splits the path two ways based on a true/false test. The Switch block routes to one of several branches by matching a value. Consider routing inbound leads by company size, so that enterprise leads reach a senior rep: A lead from a 2,000-person company takes the true branch and lands on Priya Sharma. Everyone else is distributed evenly across the team. The single trigger now produces two distinct outcomes from one canvas.

​
Passing data between blocks with variables

Each block has inputs, which are the values you configure. Most blocks also produce outputs during a run. Outputs flow downstream as variables, which is where substantial workflows get built. It is also where most mistakes happen. A block that references an output the upstream block never produced will fail at run time, not at design time. A Find records block, for example, outputs the records it matched. A later block reads that output by reference:
Feed that into a Loop block, and the workflow runs its inner blocks once per matched record. So a daily run can find every deal with no activity in 30 days and create a follow-up task on each one. The loop turns a list of records into a list of actions, all from a single scheduled trigger.

​
Knowing when a workflow is the wrong tool

A workflow is the right tool for event-driven, per-record automation. It is the wrong tool for three jobs in particular. Recognizing them early saves you a debugging session. First, a workflow is not a replacement for the API. Bulk backfills across tens of thousands of records belong in a script against the Attio REST API, not a workflow. A “backfill” means updating many existing records in one pass. Find records caps at 100 results per call, so a workflow cannot sweep an entire large object at once.
Workflow runs consume workspace credits. They cost far fewer credits than the legacy engine, but never zero for the blocks that do real work. Read Credits & pricing explained before you publish anything that runs at volume. The new engine removed per-workflow credit caps, so a runaway loop has no built-in ceiling.
Second, a workflow is not write-enabled by default. A workflow has no write access to your objects until an admin grants it. AI agents inside a workflow get read-only tool access, gated by the “Run as” permission model. This surprises everyone exactly once. See Permissions & workflow access for how to grant exactly what a workflow needs. Third, a workflow is not the legacy automation you may remember. You can no longer create new legacy workflows; existing ones keep running, and Attio says sunset notice will come “well in advance.” If you are coming from the old engine, read What’s new in the 2026 Workflows engine before you rebuild anything.

​
See also

Source: Attio Help Center: Overview of workflows. Last reviewed against the Attio Help Center, June 2026.