Migrating legacy cards to Action Flows
Action Flows are now Generally Available
After a successful Beta period, the Action Flows editor is now available to all customers and has been adopted by the majority of organizations.
- If your Atomic Organization was created after 3 April 2024, the Action Flow editor has been your default experience from day one.
- For organizations created earlier, migration is either already complete or underway. If your team still has legacy cards in use, please contact us for support and we'll help ensure a smooth transition.
Migration Status
The Beta label was officially removed in early 2025. The legacy card editor is now depreciated, and we strongly encourage all customers to complete their migration to Action Flows to ensure full support and access to the latest capabilities.
Why Move to Action Flows?
Action Flows are now the standard way to create and manage all Action Cards and push notifications in Atomic. Customers who have migrated report benefits such as:
- Greater Flexibility: Build multi-step user journeys, integrate APIs, and configure conditional logic.
- Improved resilience: Create flows that adapt to user context and deliver consistent outcomes.
- Richer analytics: Gain more granular insights into how users interact with your experiences.
- Future-proofing: All new Atomic features are built on Action Flows.
Today, most Atomic customers are already using Action Flows as their default workflow editor.
Migration is simple and easy
Your legacy cards are already Action Flows behind the scenes, so 'migrating' just means choosing to use the new Action Flow editing experience to manage those legacy cards.
Edit legacy cards in the new Action Flow editor:
- We have added a migrate button in the menu from every legacy card, which you can access from the Cards dashboard to make this choice for each card individually. Migrating a card will cause it to move to a read only state in the legacy card dashboard, and to become available for viewing and editing over in the new Action Flow area.
- Migrating a card will not require any immediate changes to your incoming event triggers, but there are some changes you should consider if/when you choose to evolve your legacy cards into more complex multi-step action flows (see differences section below)
- In the rare event that you migrate a legacy card and discover problems with the Action Flows editor, or other unexpected problems, you can choose to reverse the migration by moving the card back to the legacy card editor. This will abandon any chances you made after migration, returning the card exactly how it was before migration. This should only be done in emergencies.
Team members who will publish Action Flows may need upgraded Workbench permissions. If you hadn't already done this during the Action Flows Preview phase, publishers need to belong to a permission group that has admin level permissions to the Action Flows resource.
Important changes
Action Flows are more flexible and powerful than legacy cards because you can design them to do more than just send an in-app action card. Action Flows can contain multiple steps to send cards, send push notifications independent of cards, make API requests, and more. To make this work, some of the old ways of triggering cards will not work well with Action Flows. Here are some differences and how to deal with them:
Move your card delivery rules out of your trigger events
Old way: Card delivery settings could be defined as part of the card template, but then be overridden by delivery settings defined in the incoming trigger event payload.
New way: Since Action Flows can send more than one card, specify delivery settings individually for each card in the 'Send card' step settings instead of in the payload.
If you are sending delivery settings metadata in your existing legacy card event triggers, this will continue to work, but be cautious when modifying legacy action flows because Atomic will attempt to apply those delivery settings to any card sent by the Action Flow, in cases where you send more than one card which may lead to unexpected behavior.
Linked cards are not yet supported in Action Flows
Old way: If you wanted to send a card to a group of people (for example, all signatories of a bank account) and link them so that when the first person in the group completed the card, the copies sent to the others in the group were automatically cancelled, you could achieve this by setting the parameter { "linked": "true"} in the trigger event payload.
New way: Since Action Flows can send more than one card, linking cards using an instruction in the incoming event payload is not supported. We plan to introduce a new mechanism for achieving linked-cards behavior.
More ways to include dynamic data
Old way: To pass data values into your cards dynamically, you would create variables, which could also be overridden by variable values provided in trigger event payloads, or at runtime in your apps.
New way: Variables continue to work, and one variable can be reused between cards and steps in your flow. A new concept of 'context' has been introduced, which allows you to access variables, as well as user profile values, metadata from each step in your flow and even the response data your users have supplied. Learn more about how dynamic data works in the context article. Note: One small change is that when using customer profile values in your flows, you can no longer mark those as runtime variables.
The lifecycle of an Action Flow exists outside the lifecycle of the action cards it creates
Old way: Card instances created by Atomic from your templates each have a lifecycle which goes from an open to closed state as the card moves from created to completed (or dismissed, cancelled etc). Each individual card was an independent object in Atomic, and reporting was always focussed on showing card-level information.
New way: All the same card and system analytics continue, but Atomic now also manages the lifecycle of each instance of your Action Flows which move from started, to completed (or stopped due to errors). As well as tracking the start and completion of Action Flow instances, each individual step in your Action Flows are tracked as Atomic starts to run the step, completes the step, or errors. This enables a new layer of reporting and insights that lets you see how customers have progressed through your flows, as well as how they have interacted with the individual cards sent by the flow.
Action Flows can contain 'wait' type steps that result in customers waiting for certain events to occur. This can mean, potentially, while you are making and publishing a new/updated version of an Action Flow, some customers are still part-way through/actively participating in the current, or an earlier, published version. While this is not normally unexpected, we plan to add ways for you to cancel active Action Flows instances should you need to. You can already cancel active card instances using the cancel cards tool, but this won't explicitly cause the Action Flow to stop running, so it may progress to send a subsequent card (if that's how it was designed).
Next Steps
- Start building in Action Flows today. It's the fastest way to access new features.
- Plan to migrate any remaining legacy cards soon, as the legacy editor will no longer be supported.
- Need help? Reach out to your Atomic Customer Success Manager, jump into your team's Slack channel, or contact our support team at any time.