Most businesses want automated processes and workflows in their Salesforce orgs, and Flows are the go-to way for Salesforce teams to deliver on these requirements.
Executing business logic is rarely simple, so Flows can be pretty complicated to build. But the deployment process is even more difficult without the right tools. Using change sets, it’s easy to lose track of versions, dependencies and more. With developer tools, the XML representation of Flows is often confusing — especially for the team members usually working with Flows.
Clearly, a complicated problem requires a specialist solution. If you’ve had countless change sets fail because of Flows or want to get to grips with deploying Flows, this guide is for you.
What are Flows in Salesforce?
Flows are a powerful tool on Salesforce for adding automated business processes. They give admins and low-code developers an exciting opportunity to create business logic — what once required Apex code can now be built declaratively with a Flow. There are different types of Flow: Screen Flows involve direct interactions by end users on a Lightning page, while Schedule-Triggered Flows, Autolaunched Flows, Record-Triggered Flows, and Platform Event-Triggered Flows all run behind the scenes.
Flows are currently just part of the toolset on Lightning Flow, the process automation feature on Salesforce that contains Flow Builder, Process Builder and Workflow Rules. You can build simple automation in Process Builder, but Salesforce has been investing heavily in Flows for years. In fact, Process Builder and Workflow Rules are being retired — existing Processes will continue to be supported but you can’t create new automation. So plenty of teams are migrating from Process Builder to Flows.
What Flow metadata types are there?
There are a handful of Flow-specific metadata types you may end up working with for Salesforce Flow deployments.
- Flow. This metadata represents the Flow itself.
- FlowCategory. Flows can be grouped together, and FlowCategory is the metadata type that represents those groupings.
- FlowDefinition. In theory, Flow Definitions define the active version of a Flow. But Salesforce made significant changes to Flows in its Winter ‘19 release, and since then has recommended not using Flow Definitions.
- FlowTest. If you’ve created any tests for your Flows, those are defined with FlowTest metadata.
- FlowSettings. This metadata captures a whole range of possible settings, e.g. whether users can pause Flows.
- FlowAccessess. This is a field on your Profiles or Permission Sets metadata that controls which Flows users have access to.
How to deploy Flows using Change Sets
While Flows are complicated to build, deploying them brings additional challenges. There’s a few additional considerations when deploying Flows with Change Sets:
- Make sure you include any components that your Flow references in your outbound change set. This can be especially tricky as if your flow element references these components, the Component Dependencies page won’t display the components and you’ll have to manually add them.
- You can only include one version of the Flow in the Change Set.
- Deploying a Flow will create a new version of the Flow in the target org.
- An active Flow in an outbound Change Set is automatically deployed to its destination as inactive, so you’ll have to manually activate the Flow once you’ve completed the deployment.
Using Change Sets to deploy Flows can lead to a lack of visibility, overwritten changes and failed deployments as you need to manually add Flow dependencies, remember to activate Flows in your target org, and keep track of versions (and their limits!).
How to understand Flow XML
For teams using developer tools such as SalesforceDX or CLIs like VSCode, things don’t get much easier. Flow XML is unreadable and confusing, containing noisy location changes and elements that are in the wrong order.
So when it comes to understanding the changes you’re deploying, it can be difficult to actually understand what’s included in your Flow. What version is it? What were its most recent changes? Does it include this specific element? This all creates a huge amount of difficulty when it comes to deploying Flows, especially when you work in a large team where multiple admins may be working on a Flow at the same time. It’ll leave you wondering whether deploying your most recent changes carries the risk of deleting someone else’s work, and likely relying on manual testing to make sure you haven’t overwritten or missed something.
Unfortunately, without a specialist solution, your best bet is either to blindly deploy your changes and hope you can unpick them in production, or to comb through the XML line by line to spot differences between your Flows in your development and production environments.
How to manage Flow versions
To make matters worse, managing versions is another awkward feature of Flow deployments. Each time you make changes and save them, you create a new version of your Flow in that org. Salesforce imposes a limit of 50 versions for each Flow — if you reach that limit you’ll need to delete older versions or you’ll be hit with the Salesforce error message maximum flow versions reached in Flow Builder when you try to save a new flow.
These versions make deployments tricky. Historically, the Flow versions in your org were reflected in the API name of the Flow, e.g. MyFlow-1. Salesforce removed those version numbers in 2019, so that Flows would be easier to handle in source control. You’ll find our full explanation of the changes to the Metadata API in the Winter ‘19 release here, but there were two key implications:
- Flow versions easily get out of sync between orgs. When you deploy a Flow, it’s added to the target as a new version. The version number depends on the target org. If you iterate on a Flow in a dev org and end up deploying v5 to a target that currently has v2, it will be added as v3.
- It’s hard to deploy anything other than the latest Flow version. Since v44, the Metadata API only fetches the latest version of your Flow — whether it’s active or still in draft. If you need to deploy your latest active version but have begun drafting a new version, you need a workaround. This is where the semi-retired Flow Definitions can come in handy.
Gearset address these challenges to help you manage Flow versions:
- When you compare and deploy your metadata with Gearset, you can see everything that’s new, changed, or deleted. And you can see the exact changes you’re deploying, including the status of your Flows. Regardless of the Flow versions in your orgs, you’ll have full insight into the impact of your deployment before you deploy.
- With Gearset, you no longer need to worry about Flow Definitions and can easily deploy versions other than the latest. Our Flow Navigator lets you change the version of the flow on the source side of your comparison. Check out the walkthrough below to see it in action!
Catching Flow dependencies
Missing dependencies are a classic cause of deployment failure, and Flows are a common culprit because they usually connect to lots of other metadata. There are the custom objects and fields your Flow interacts with, any list views and workflow alerts your Flow uses, and even other Flows if you have Flows triggering other Flows!
Gearset’s advanced dependency tracking and problem analysis helps you get your deployment packages right the first time. You can see all the dependencies between your metadata during any deployment. Even if you miss any items, one of Gearset’s problem analyzers will catch the missing dependencies and offer to add them to your deployment package.
How to deploy Flows using Gearset
All admins are faced with the challenges of versioning and dependencies when it comes to deploying Flows. For many Salesforce teams out there, releasing updates to Flows feels like it always runs the risk of overwriting someone else’s work, a failed deployment or desynchronizing your environments.
As Flow deployments are a common cause of pain in every admin’s life, Gearset has a custom Flows solution to help you deploy successfully first time and collaborate with your team.
Let’s look at how to deploy Flows with Gearset. There are only a few steps you need to take for a successful deployment — you can sign up for a free trial of Gearset and follow along.
Step 1: Configure your comparison to include the right metadata
Select the source and target environments for your deployment — whether you’re deploying to an org or committing to source control, the workflow is the same. Then click Compare Now.
In the left hand toolbar, use the dropdown menu to select your comparison filter. Our default comparison filter includes every metadata type you need for Flow deployments: Flow and FlowCategory, alongside Custom Object for any dependencies. You can also select any managed packages that your Flow depends on, too. You can check that the correct metadata types are included in your comparison by searching for them.
Step 2: Check the Flow version with Flow Navigator
Once you’ve compared the metadata in your source and target, Gearset’s Flow Navigator will display which items are new, changed, or deleted, and exactly what’s different for each item. You can see which version of the Flow has been retrieved from the source. This helps you to identify whether you’re looking at your draft changes in the latest version, rather than the active version that you intended to deploy. You can even change the version if you need.
Step 3: Identify differences between your source and target org
As Flow XML can be difficult to understand, Flow Navigator renders the Flow as it looks in Flow Builder, with changes highlighted. The interactive diagram and element sidebar then give you a high-level overview showing what’s changed in your Flow, and where those changes are.
You can drill down into each element and resource to see exactly how they’ve changed. Our element visualizers show the changes in an easy-to-read format, meaning you don’t need to figure out what all of the XML means.
Step 4: Build your deployment
By clicking on the dropdown for any item, you’ll see all of its dependencies.
If your source and target are significantly out of sync, you may need to deploy any custom objects and fields your Flow depends on first — avoiding a bunch of validation errors.
Select the metadata items you want to deploy and click Next.
Step 5: Deploy to your target environment
Gearset’s problem analysis will flag any issues with your deployment, including a host of Flow-specific errors. Once you’ve accepted any suggestions to make the deployment more likely to succeed, click Pre-deployment summary.
Step 6: Deploy a Flow as active
Deploying a Flow as active is at worst impossible or at best a hassle with most solutions. But Gearset’s pre-deployment summary includes an Activate Flows after deployment toggle — no need to log in to the org and do it manually, mess around with deploying Flow definitions, or worry about forgetting to activate Flows.
Step 7: Validate and deploy!
The pre-deployment summary also gives you the chance to check over the package, give it a friendly name, and leave any notes for your teammates.
Clicking Validate deployment is always a good idea, then hit Deploy now or click on the drop-up to schedule the deployment for a release window. You can download a report of the deployment from your Deployment history, where you can also redeploy to another org or roll back.
If you run into any unexpected issues, just reach out via the live chat! Our deployment experts are super speedy and available to help you get those changes live.
Help! How do I delete a Flow?
Deleting old Flow versions is critical to org health. For example, if an old version references a custom field, you won’t be able to delete that custom field. You might think you’ve removed all references to the custom field, when in fact there are still some lingering around for no good reason.
Trying to delete a Flow is yet another source of potential frustration, and there are two problems to overcome. Firstly, you can’t delete an active Flow. The second problem is more of a conundrum: in order to delete a Flow, Salesforce needs you to specify every version of the Flow, but from v44 of the Metadata API onwards you can’t retrieve and deploy specific versions.
Depending on the API version you use, you’re likely to hit one or both of these errors:
Insufficient access rights on cross-reference idYou cannot delete this Flow version because it is active. Deactivate it, and try again.
Thankfully, Gearset’s problem analysis resolves all of this for you. It disables the Flow, retrieves and deploys all the versions of the Flow, and deploys the destructive change successfully.
Get your deployments flowing!
Keep delivering the Flows that power your business’s automation, without getting blocked on deployments. Using Gearset is guaranteed to see more of your deployments work first time.
If you want to see Flows in action, book a demo with one of our Salesforce DevOps experts. Or, try it for yourself with a free 30-day trial.
