Migrate your legacy workflows
Learn how to migrate a legacy workflow to the new workflows engine by using Ask Attio to recreate it automatically, then reviewing, testing, and cutting over safely.
Available on all plans.
Available for all workspace members.
This article walks you through how to move your existing legacy workflows over to the new workflows engine.
The fastest way is to let Ask Attio migrate a workflow for you, double-checking before publishing. If you'd rather rebuild yourself, the manual path is covered further down.
Why migrate?
The new features and refined pricing we’ve introduced for new workflows make them more capable and cheaper to run, so we recommend moving your legacy workflows over.
That said, your existing legacy workflows will continue running for now. You’ll receive notice well in advance before we sunset legacy workflows.
New capabilities
Agent builder: describe a workflow in natural language and have Ask Attio build it for you.
Custom Agent block: run a configurable AI agent as a step in a workflow, with access to MCP-connected tools.
Web Agent block: research a record with AI and web search from a workflow step.
Execute code block: run custom JavaScript as a workflow step.
New Ecosystem blocks: workflow blocks for Webflow, Notion, Linear, and more.
Multi-trigger support: a single workflow can respond to more than one trigger event.
Advanced variables: chain multiple data sources inside a single variable so the workflow uses the first source that returns a value.
Retry, pause, and resume: control in-flight runs.
Copy and paste blocks: move blocks between workflows and across workspaces.
Custom workflow blocks via the App SDK: build your own workflow blocks using Attio's App SDK.
UI improvements: copy and paste blocks between workflows and workspaces, drag blocks from the sidebar onto the canvas, build HTTP request payloads with a visual JSON editor, and drop blocks from outside a loop directly into the loop, and more.
Better pricing for most workloads
Block category | Legacy workflows | Workflows |
|---|---|---|
Internal triggers (record updated, attribute changed, scheduled, manual) | Free | Free |
External triggers (e.g., Typeform, webhook) | Free | Free |
Logic and control blocks (If, Switch, Loop, Delay, Broadcast, Round-robin, Celebration) | 1 credit | Free |
Data lookups (Find records, Find entries, Calculation, Aggregate values) | 1 credit | Free |
Data writes (create, update, or delete records, entries, tasks) | 1 credit | 1 credit |
External pushes (Slack, webhooks, sequences) | 1 credit | 1 credit |
AI blocks (Classify, Summarize, Research record/Web agent, Custom Agent) | 1 credit (Classify, Summarize, Prompt completion) 10 credits (Research record) | Variable (token-based)* |
Code execution | Not available | 1 credit |
The new pricing applies only to the new workflows engine. Legacy workflows retain their existing credit pricing.
*Now that AI blocks are priced based on token usage, the ability to set limits on credit consumption per workflow run has been removed. Learn more in our guide on workflow credit usage.
Before you start
Your existing legacy workflows will continue to trigger and execute until you disable them.
You can't create new legacy workflows. Existing legacy workflows remain fully editable, but the option to create a new one is no longer available.
Ask Attio can read your legacy workflow and recreate it for you (see Step 1), and if you'd rather rebuild manually, the manual path explains how to document and rebuild your workflow.
Step 1: Migrate with Ask Attio
Ask Attio can read an existing legacy workflow and recreate it as a new workflow for you. This is the fastest way to migrate and the recommended starting point for most workflows.
If you’d rather not use Ask Attio to migrate your workflows, see the Rebuild your workflows manually section below, and then return to Step 2.
Ask Attio will read the current published version of your legacy workflow, so make sure you’ve published any changes before running the migration.
Navigate to Automations in the left sidebar and open the legacy workflow you want to migrate.
Click Ask Attio in the top-right of the workflow view to open the Ask Attio panel.
Ask it to migrate the workflow. For example: "Migrate this workflow for me."
Ask Attio will create a new workflow based on the legacy one. When it's done, it gives you:
An overview of the workflow it built.
A list of anything that needs your attention.
A link to the new workflow.
The new workflow is created but not enabled, so it can’t be triggered until you turn it on.
Review the migration
Check every block before you publish. Ask Attio recreates your workflow automatically, but AI can make mistakes. Don't assume the migration is correct because it looks right at a glance. Go through the new workflow block by block, confirm each one matches the legacy version, and resolve everything Ask Attio flagged before you enable it.
Open the new workflow using the link Ask Attio provides, and review it against the legacy version paying particular attention to anything Ask Attio flagged.
Some blocks and options have been renamed or work differently in the new builder. If something looks unfamiliar, or a flagged item doesn't have an obvious equivalent, check the Block changes reference below.
Common things to verify:
Variable references: any blocks that outputs values are correctly wired to the downstream blocks that reference it.
Trigger conditions and filters: these match the legacy workflow.
Note: The filter conditions UI looks different in the new builder compared to legacy workflows. The filtering logic works the same way, but field labels and layout have changed. Learn more about the updated filter conditions.
Step 2: Test the new workflow
To test a migrated workflow, you have to publish it. You’ll need to decide what to do with the legacy workflow while you test, because it will be listening for the same trigger as the new workflow.
You have two options:
Leave the legacy workflow enabled: while both workflows are enabled, any event that meets the trigger will kick off both workflows, which risks duplicate actions. The upside is that no actions get missed during testing.
Disable the legacy workflow first: this prevents the two workflows duplicating the same actions, but the migrated workflow becomes the only one handling the trigger before you've confirmed it works. If it fails partway through a real event during the test, you won’t have the legacy workflow to fall back on.
For example, if your legacy workflow notifies the sales team via a Slack notification when a deal closes, and you disable the legacy workflow to test the new one, a deal that closes during the test won't notify the team if the migrated workflow doesn’t complete as expected.
Leaving the legacy workflow enabled at the same time as publishing the new one for testing is usually the lower-risk option, because duplicated actions are often less of a problem than missed actions (having two Slack messages about the same closed deal is better than no messages about the closed deal). For a high-volume trigger, or one where duplicate actions would be costly or hard to reverse, disable the legacy workflow first and test during a low-traffic window.
If your migrated workflow uses a Manual run or Record command trigger, the trade-off is smaller. Once published, the workflow runs only when you trigger it, so you can leave the legacy workflow enabled as well as enabling the migrated workflow, then run the migrated workflow with little risk of duplication.
To run the test once the migrated workflow is enabled:
Cause the workflow's trigger event to occur. How you do this depends on the trigger: for a Manual run trigger, click Trigger workflow; for a Record command trigger, click Run workflow on a record and click on the workflow from the list. For any other trigger, perform the event it listens for, using test data where you can so live records aren't affected.
Open the Runs tab to view the step-by-step output.
If a block fails or produces an unexpected output, click the run log entry for that block to see the error detail. For more help, see our guide on troubleshooting workflows.
Confirm the migrated workflow's output matches what the legacy workflow produced, then you can leave it published and move on to the next step.
Step 3: Cut over
Once you're confident the newly migrated workflow is running correctly, disable the legacy workflow.
Navigate to Automations and open the legacy workflow.
Toggle the workflow off to disable it. Disabling a legacy workflow doesn't delete it, so you can re-enable it if you need to roll back.
Block changes reference
Several blocks and configuration options have been renamed or changed in the new builder. Use this table when reviewing a migrated workflow, or when rebuilding one manually. If you search for a familiar name and can't find it, check here first.
What changed | In legacy workflows | In workflows |
|---|---|---|
Data trigger name | Attribute changed | Attribute value changed |
Conditional block name | If/else | If |
Summarize record block input | Guidance | Instructions |
Prompt completion block | Separate block | Subset of the Custom agent block |
Switch block path labels | Condition 1, condition 2, etc. | Case 1, case 2, etc. Customizable. |
Celebration block option name | Confetti | Ceiling drop |
Multi-select overwrite option | Overwrite multi-select values | Replace values (on the Create or update record block) |
Slack message format | Slack markdown syntax | Standard markdown. No 'Don't expand links' option |
Variable picker record URL | Record URL | Attio URL |
Canvas notes | Available | Not available |
Rebuild your workflows manually
If you'd rather rebuild a workflow yourself, you can recreate it block by block.
Document your legacy workflow
Open your legacy workflow in one browser tab and the new workflow builder in another, so you can work through the build side by side.
Before switching to the new builder, note down anything that's easy to lose track of across two tabs:
Which blocks pass values to downstream blocks, and how those values are referenced.
Any trigger conditions or filters with multiple rules.
Block configurations that involve more than one input.
Rebuild in workflows
With your legacy workflow documented, create the equivalent workflow in the new builder. Don't enable it yet. You'll test it in Step 2 and cut over in Step 3.
Navigate to Automations and then Workflows in the left sidebar.
Click New workflow.
Then configure the trigger to match your legacy workflow, add and connect the remaining blocks, and configure each block's inputs. Pay close attention to:
Variable references: verify that any block outputting a value is correctly wired to downstream blocks that consume it.
Conditional blocks: if your legacy workflow used Filter, If/Else, or Switch blocks, make sure the conditions are configured the same way.
Use the Block changes reference above when a block or option doesn't look the way you expect. Once all blocks are connected and configured, your new workflow should be a functional equivalent of the legacy workflow. Continue to Step 2 to test it.