What are flows?
A flow is an application that automates a business process; they gather information and use it to do something in your Salesforce org. Flows are one of the many tools on the Salesforce platform that have been developed to assist an existing business process. Flows are complex, can be built declaratively and can be used for a behind the scenes automated process or a guided visual experience.
To learn more about developing flows, there is a Salesforce Trailhead module here, which can get you started learning the basics, or provide a refresher.
There are a few pieces of terminology used to refer to flows, but these are the official Salesforce terms:
Flow- With flow metadata, you can create an application that navigates users through a series of screens to query and update records in the database.
Flow Builder- A point-and-click tool for building flows.
Lightning Flow- The product that encompasses building, managing, and running flows and processes.
FlowDefinition- Represents the flow definition’s description and active flow version number.
FlowCategory- Represents a list of flows that are grouped by category. Flows aren’t added directly to a Lightning Bolt Solution. Instead, add the category the flows are in to the Lightning Bolt Solution
FlowSettings- Represents the org’s settings for processes and flows, such as whether Lightning runtime for flows is enabled.
There is also the (as yet not officially documented)
FlowAccesses metadata. After it was brought to our attention we wrote up a blog post here in order to help users who were finding this mysterious new metadata in their comparisons.
FlowAccessess- A subcomponent of
flowAccessesseems to be the metadata that allows you to choose exactly which flows your users can or can't run, by restricting access to certain flows.
There are still a lot of questions we have about the
FlowAccesses metadata type, but until Salesforce officially releases something explaining it, this is the basis we're working on.
What do you need to include in your metadata filter to see flows in your comparison?
As we know, flows are automated processes that can query and update other parts of your org. So as well as the
Flow category and
Flow definition metadata types you should also include the
Custom object metadata that the flow depends on.
If the flow depends on managed package metadata, you should also include managed packages.
How to deploy a new flow
To deploy a new flow, you need to find the metadata in the comparison results and select it.
Because flows are a metadata type that depend on the rest of the org, if there are significant differences between the source and target, they may fail validation. However, this also means that validation errors related to flows can be resolved by making another deployment to resolve the differences between the two environments, and then deploying the flow in a second smaller deployment.
For example, if the flow depends on custom objects or fields that exist in the source and not the target, you should deploy these first, to avoid validation errors.
What needs to be present in your target environment for a flow deployment to be successful?
Gearset has the ability to map dependencies of metadata in a way that makes them clearly visible in your comparison results.
To find out what your flow depends on, you can click the dropdown arrow next to the API name, and then the drop down next to the
Depends on information.
If you do not see any dependencies here it may be because your comparison filter is too restrictive. You can update your metadata selection and refresh the comparison by clicking on
Refresh comparison in the bottom left of the comparison results.
Deploying a flow with multiple versions
It is common to have more versions of your flow in your source than your target, as this will have been where changes have been made and saved as new versions of the flow. Deploying a flow will transfer the latest version of the flow from the source into the target.
Can you deploy flows to a version control system?
Yes, you can deploy flows to and from your version control systems in the same way as any other metadata. Because flows are prone to validation errors, you may want to set up automatic validation of pull requests against the orgs in your CI workflow.
By default, active flows are deployed as inactive, and after deployment you will need to reactivate these flows. It is possible to change this default behavior if you are deploying flows as part of a continuous integration process.
If you are deploying a change to a flow version which is already active, or was once active, in the target, you might hit a validation error as a deactivated version might still have running or paused executions. The solution is to deploy your changes as a new flow version.
You may not be able to see a previous version of your flow because in the v44 release Salesforce made a change to the way flows work. After v44 the API no longer retrieves version numbers; instead, they're named according to the convention
MyFlow.flow. Only the latest version of the flow will be retrieved. We have more details on the this change in our blog post we wrote at the time, here.
If the comparison is too restrictive, key junction items may not be retrieved, which may exclude some of the elements you're expecting to see. Refreshing the comparison with the
Compare allmetadata filter selected will confirm whether the filter is the issue.