Loading tutorials…
Loading tutorials…
Attio Workflows are the operational core of the platform — assign owners, send Slack pings, update stages, sync to other tools. Build them carelessly and they fire 800 times the first weekend and you spend Monday unwinding. Build them with discipline and reps stop doing repetitive busywork. Here is the discipline.
Who this is forOps leads, RevOps owners, and admins setting up the first wave of Attio Workflows — or anyone debugging a workflow that 'should be running but is not.' Requires Plus or Pro plan for Workflows.
What you'll need
Step 1
Every Attio Workflow is built from a Trigger (what starts it), Conditions (when to run), and Actions (what it does). Misorder these and the workflow fires the wrong records.
Open Attio → sidebar → Workflows → Create workflow.
Trigger: the event that starts the workflow. Examples: "Record created," "Attribute updated," "Record matches filter," "On a schedule (daily / weekly)," "Webhook received."
Conditions: filters that gate whether the workflow proceeds. Always include conditions — without them, every record matching the trigger fires the workflow.
Actions: what happens. Examples: "Update attribute," "Send Slack message," "Send email," "Create a record," "Call an API," "Add to list."
Workflows run top to bottom. Each step can reference outputs of previous steps. Test execution path on sample records before activating.
Step 2
Choose the most specific trigger possible. "Record created" fires on every new record; "Record created AND Source = LinkedIn" fires only when you actually want it to.
"Record created" — best for onboarding flows ("when a new Company is created, assign to round-robin owner"). Be careful: this fires on bulk imports too. Add a condition to exclude.
"Attribute updated" — best for state changes ("when Deal stage changes to Closed Won, send Slack celebration"). Specify which attribute and what value to watch.
"Record matches filter" — fires when a record newly matches a filter ("Person matches lifecycle = MQL"). Powerful for handoff flows.
"Scheduled" — runs on a cron schedule ("every Monday at 9 AM, post pipeline summary to Slack"). Best for digests and audits.
"Webhook received" — fires when an external system POSTs to Attio. Best for tying in tools without a native integration.
Step 3
Without conditions, every triggered event fires the actions. Add conditions to gate based on owner, status, time range, or any attribute.
Common condition patterns: "Owner is set" (skip orphaned records), "Status ≠ Closed" (skip terminal records), "Created > 5 minutes ago" (skip bulk imports), "Source = X" (only handle specific lead sources).
For attribute-update triggers, condition on the new value AND old value if relevant ("Stage changed from Open to Closed Won" — not just "Stage changed").
Combine multiple conditions with AND / OR. Test edge cases: records with empty fields, records with unexpected values.
When in doubt, add more conditions. Workflows are easier to widen later than to recover from misfires.
Step 4
Idempotent means safe to run twice. Critical for "update attribute" actions that might re-fire if the trigger event repeats.
For "Update attribute" actions: use "Set value" (always overwrites) carefully. Prefer "Set only if empty" when you want a default value but not to overwrite a rep edit.
For "Send Slack message" actions: include a record reference + workflow name in the message. If it fires twice, you can debug from the message itself.
For "Create record" actions: include an idempotency key (e.g. an external ID) so a re-fired workflow does not create duplicate records.
For "Call an API" actions: use the receiving API's idempotency token if it supports one. Stripe, HubSpot, and most modern APIs do.
Test idempotency: run the workflow twice on the same record. Does the second run cause damage or silently no-op? Silent no-op is the goal.
Step 5
Start with the 5 universally useful workflows. Resist the urge to build 20 on day one — the maintenance cost is real.
1. Round-robin owner assignment: Trigger "Company created" with condition "Owner is empty" → Action "Set owner = next in round-robin list."
2. Stuck-deal Slack ping: Trigger "Scheduled daily at 9 AM" → Filter "Deal stage = Open AND Last activity > 14 days" → Action "Send Slack DM to deal owner."
3. Stage-change celebration: Trigger "Deal stage updated" with condition "New stage = Closed Won AND Deal value > $X" → Action "Send Slack message to #wins channel."
4. MQL handoff: Trigger "Person attribute updated" with condition "Lifecycle = MQL" → Actions "Assign sales owner," "Add to Sales SDR list," "Send Slack DM to owner."
5. Renewal reminder: Trigger "Scheduled daily" → Filter "Contract end date in next 60 days" → Action "Send email to CSM owner with renewal checklist."
Step 6
Every workflow needs to be tested on real-shaped data before going live. Test bad cases (missing fields, wrong owner) too.
In the workflow editor, click "Test run" → pick a sample record → watch the execution log.
Verify each step executed as expected. Check the action target (Slack message landed in the right channel, attribute updated to the right value).
Run on a bad-case record: missing attribute, empty owner, terminal status. Does the workflow gracefully skip or does it error?
After fixing any issues, activate. Watch the workflow run logs (Workflows → click workflow → Run history) for the first 24 hours. Catch misfires early.
Document the workflow externally (Notion / wiki): what it does, why, what conditions, what triggers. Future-you will not remember in 6 months.
Step 7
Workflows fail silently when source attributes change, integrations drift, or APIs rate-limit. Weekly review catches drift early.
Workflows → click workflow → Run history. Look for runs marked "Failed" or "Skipped unexpectedly."
For failed runs, click into the run log to see which step failed and why. Common causes: missing attribute, invalid API token, Slack channel deleted.
For workflows with high run counts (1,000+/day), check for over-firing. Conditions may need tightening.
Quarterly: audit every workflow. Is it still needed? Has the business motion changed? Delete or update accordingly.
Treat workflows like code. They have an owner, a purpose, and a maintenance burden.
Common mistakes
Triggering on "Record created" without filtering bulk imports
What goes wrong: First CSV import of 5,000 People fires the welcome-Slack workflow 5,000 times. Slack workspace is flooded for 20 minutes. Reps mute the channel. The workflow is now useless. If the action sends an email instead, you have just torched sender reputation across 5,000 contacts — recoverable, but easily a $2-4K incident in deliverability lost.
How to avoid: Add a condition like "Created within last 5 minutes" or "Source ≠ CSV Import" to exclude bulk creates. Test on a 10-row import before unleashing a 5,000-row one.
No conditions on the trigger — every event fires the action
What goes wrong: Trigger is 'Deal stage updated.' Action is 'Send Slack message.' Reps update stage 80 times a day. The #sales-ops channel is unreadable. Real signal gets lost in noise.
How to avoid: Always condition the trigger. "Stage updated to Closed Won AND value > $10K" is signal. "Any stage update" is noise.
Building actions that are not idempotent
What goes wrong: Workflow fires once, then fires again on a retry. Action 'Create a Task' runs twice. Now the rep has duplicate tasks. Multiply by 50 events/day = 25 ghost tasks weekly. Reps lose ~30 min/day triaging — at $80-120/hr loaded, that is $800-1,500/month per rep of dead time.
How to avoid: Design actions to be safe to re-run. Use "Set only if empty" for attributes, idempotency keys for create actions, "no-op if exists" patterns for downstream tools.
Workflows that nobody owns and nobody documented
What goes wrong: Six months in, there are 22 workflows. Three are stale, two are misfiring, the rest nobody can explain. Anyone editing the data model breaks something but does not know which workflow.
How to avoid: Every workflow gets an owner (named in description) and a one-paragraph doc (why it exists, what triggers, expected volume). Quarterly review.
Not testing on bad-case records before activating
What goes wrong: Workflow assumes every Person has a Company. Live activation hits a Person with null Company. Workflow errors. Reps wonder why the Slack ping never came; nobody catches the error for two weeks.
How to avoid: Always test on a bad-case sample (missing field, wrong owner, terminal status). Add graceful skip conditions for known edge cases.
No monitoring after activation
What goes wrong: Workflow was tested, activated, then forgotten. Slack API token rotated 90 days later — every workflow that sends to Slack silently fails. Three months of missed handoff notifications. If even 5% of MQLs got dropped on the floor, that is $20-50K in pipeline lost depending on ACV.
How to avoid: Weekly: scan Run history for failed runs. Set up a Slack alert when any workflow has 3+ failures in a row (use a meta-workflow). Treat workflows like production code.
Recap
Done — what's next
How to set up the Attio data model without making a mess
Read the next tutorial
Hand it off
Workflows are where Attio's leverage compounds — or where you build a chaos engine. A specialist who has built 100+ Attio workflows knows which patterns survive contact with reality, how to handle errors gracefully, and how to keep the library lean. EverestX Attio specialists run $400-1,200/month at $14-16/hr.
See specialist rates
No — Workflows require Plus or Pro. The Free plan supports manual record updates and basic notifications, but not multi-step Workflows with triggers/conditions/actions. Most teams upgrade to Plus specifically for Workflows once manual operations become repetitive.
Workflows run inside Attio with native access to records and attributes — faster, no API rate limits, no external dependency. Zapier/Make are better for connecting Attio to external systems that lack native integration. Rule of thumb: in-Attio logic = Workflows, cross-tool plumbing = Zapier/Make. Often you use both.
Yes — the 'HTTP request' action lets you POST/GET to any external API with custom headers, body, and auth. Useful for tying into systems without a native integration. Watch the rate limits of the receiving API and use idempotency tokens to handle retries safely.
Workflows → click the workflow → toggle 'Active' off. This stops new runs immediately; in-flight runs may still complete. For mass cleanup of incorrect attribute updates, export the affected records, fix in CSV, re-import. Always have a rollback plan documented before activating a destructive workflow.
There is no hard cap on Plus or Pro, but practical sanity is 10-25 active workflows for a sub-50-person team. Past that, maintenance burden outweighs value. If you feel you need more, consolidate similar workflows into single workflows with branching logic.
Attio
Attio's data model is its superpower and its trap. Anything is customizable; that means anything is also rewritable into a mess. Get the objects, attributes, and relationships right up front and the rest of the workspace (workflows, views, reports) glides. Get them wrong and you rebuild every 90 days.
Attio
Lists and Pipelines are how Attio teams turn the data model into an actual sales motion. Lists hold the cohorts (ABM target, sequence enrollees, onboarding cohort); Pipelines move records through stages. Build them well and forecasting is real. Build them poorly and you live in spreadsheet exports forever.
Attio
Attio's API is the under-rated power of the platform. A clean REST surface, webhooks for every event, and OAuth for partner apps. Used right, it makes Attio the spine of your stack. Used wrong, it leaks tokens, double-writes records, and spirals rate-limit costs. Here is the discipline.
Attio
DIY Attio is a great idea — until it isn't. This is the honest framework for when the cost of self-managing exceeds the cost of hiring help, and how to tell which side you are on.