How to deploy flows in v44

Catherine Bacon on

Share with


In the Winter ’19 release (v44 of the metadata API), Salesforce made several changes to how flows work. There are some important changes to how this type of metadata should be deployed - read on to find out more about working with them in the latest release.

No more version numbers

If you’re familiar with using Gearset to deploy flows, you’ll be used to seeing a list of each version of each flow in our comparison grid, following the naming convention MyFlow-<version-number>.flow.

Results screen showing a list of flows with the '-<version-number>' name format

The first big change in v44 is that Salesforce has done away with these version numbers when retrieving flows via the metadata API. Although nothing has changed in the Salesforce UI - flows are still versioned just as they were before - the API no-longer exposes this versioning. This means when looking at flows in Gearset, they’re named according to the new convention MyFlow.flow. This also affects how flows work with the Metadata API - we now only get the latest version of the flow from Salesforce, which means you can only deploy the latest version via the metadata API, and thus via Gearset.

Results screen showing a list of flows with the v44 name format

Goodbye to flow definitions; hello to new ways to set flow status

Salesforce recommends discontinuing the use of flow definitions to set the active status of flows, likely to make them more SFDX-friendly. The imposed versioning inherent to flows conflicts with the use of version control systems - maintaining multiple files with prepended version numbers is at odds with tracking changes to individual files over time. As a result, the flow xml itself now contains the status element, meaning you only need to deploy the flow in order to activate or deactivate it.

Status tag in the xml of a v44 flow

Changes to behaviour during deployments

It’s well documented that you can’t make changes to an active flow in an org, and instead any changes have to be saved as a new version, and that new version activated. Prior to v44, if you tried to deploy a change to an active or obsolete flow, you’d receive a deployment error. When using v44 and source control, however, you can make a change to the flow’s metadata and deploy it over the current active version. With this change, when attempting to deploy such a change to an active flow, Salesforce dutifully creates a new version of the flow in the target and activates it for you - simple!

It’s also possible to still use the flow definition to switch which flow is active, in the same way as with v43 and earlier. This comes with a note of caution though - flow version numbers between orgs are no longer linked, because Salesforce will automatically create a new version in the target with each flow deployment. This is a very good reason to stop version controlling and deploying your flow definitions.

Updating source control

These naming changes can get you in a pickle if you use version control, especially if you’re migrating from v43 to v44, or comparing and deploying across API versions. To help, Gearset will detect which API version we think you’re using based on the Flow naming convention in your version controlled metadata, and it’ll select the API version to use accordingly.

Salesforce has some suggestions of how to convert your repository to v44. If you have a package.xml file you can set the version to 44.0, then remove any old versions of flows that are still named by version number, and then retrieve again. The result should be a folder containing a single version of each flow, without any appended version numbers. With Gearset, the process is even simpler - just run a comparison from your source org to your git branch, selecting API version 44 from the configure comparison dialog. After running the comparison, you should find that all versioned flows are marked as deleted, with a single unversioned instance of each flow either marked as changed or created. Select all of these changes to your flows and commit them to your branch. As a final step, you can manually delete any flow definitions from your branch - with Gearset this is an optional step, as the default comparison now excludes flow definitions anyway.

How can Gearset help?

We also have several problem analyzers which help make deploying flows easier, regardless of which API version you’re using. We’re adding to these all the time, but if you see any gaps, let us know by adding them to our feedback forum!

Ready to get started with Gearset?