Migrating legacy cards to Action Flows
Action Flows are now in Beta
Following the successful private preview phase, we're excited to confirm the Action Flows editor is now available to all new and existing Atomic accounts.
- If your Atomic Organization was created after 3 April 2024, the Action Flow editor will be how you create and manage all Action Cards and push notifications in Atomic.
- Customers whose accounts were created prior to 3 April 2024 will be invited to turn on the Beta in their Atomic Orgs on a rolling basis, and we will provide you support and advice to assist you in migrating from the legacy card editor to the new Action Flow Editor at a pace that suits you.
We're classifying the new editing experience as Beta to signal that, while the new editing experience is production ready, there are still many improvements and refinements to both the Workbench user experience, and overall capability that we are actively making. Like all our Betas, we strongly value your feedback and ideas. Please reach out to us at any time to share your experiences.
If your organization doesn't yet have Action Flows enabled and you want to jump the queue reach out to us. For most customers, the switch will be quick and easy, and we'd love to help you get started when you're ready.
What's new?
- With the introduction of the Action Flows Beta, all Atomic customers will see a new area in the Workbench named 'Action Flows', where a new editing experience is available to configure how Atomic will send action cards and push notifications.
- We are encouraging customers to begin using Action Flows created via the new editing experience, to get the benefits of the power and flexibility they provide. For customers who had Atomic orgs created before 3 April 2024, you can still use the legacy editor to maintain existing cards, and as needed, continue to make legacy cards.
- As we progress through our Beta phase, we expect to receive and respond to your feedback as quickly as possible to ensure the new editing experience works for you, and we expect to remove the Beta label later in 2024. At this time, the Legacy card editor will be deprecated, and we will share a timeline for requiring all customers to migrate.
You can set the Action Flows dashboard as your default home screen, instead of the Cards dashboard, by editing your profile settings.
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 Beta 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 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 as we progress through the Beta.
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).
We're here to help
We understand that changing the editing experience will impact your teams, even just by asking them to learn new ways of working. We also appreciate that changes like these can cause knock-on effects to your in-house processes, and documentation. This is one of the reasons we're staging our rollout of Action Flows slowly and cautiously from Preview (which many of you have participated in), then to Beta (now) because making it the only way to get things done (later).
To help you get up and running in Action Flows, and to help us find and fix any rough edges along the way, we are here to support you as closely as you need.
- Chat to your customer success team about how we can provide training, assistance and advice
- Please make time for you team to play, and chat to us about how we can help there too
- Let us know if you'd like examples, templates, or tips on how to build flows
- If you have questions at any time, jump into your teams Slack channel, or reach out to us via our support system
- If you spot any errors, or gaps in our documentation please let us know so we can improve
- When you have ideas for new Actin Flow features, we'd also love to hear about them, and how you'd use them.