Skip to main content
Managing Salesforce Flows

This article explains the behavior when deploying Flows with Salto, along with some considerations for managing flow versions.

Support avatar
Written by Support
Updated over a year ago

Flow Versions

Salesforce allows multiple versions of a flow to exist, while only one of those versions can be active at a time.

Your Salto environment will only show the most recently created version by default. This means you will only see this version, even if it’s not the activated one. In the example above, by default Salto will show version 4, even though version 3 is active.

This can be problematic because you will not see the active version of the flow in your environment, which means you won’t be able to deploy changes to it, etc.

Salto offers a preferActiveFlowVersions flag in its Salesforce adapter configuration to address this issue. This flag is disabled by default. When enabled, Salto will fetch the active version of the flow (or the most recent version if no active version is available).

Deploying Flows

The behavior when deploying flows depends on the org type (sandbox vs. production) and the flow type. The official Salesforce documentation states:

By default, active processes and flows are deployed as inactive. After deployment, you manually reactivate the new versions. In production orgs, you can enable the setting to deploy a new active version of a process or flow via change sets or Metadata API. The setting doesn't appear in non-production orgs (such as scratch, sandbox, and developer orgs), because you can always deploy a new active version.

If you use a continuous integration and continuous delivery model to deploy metadata changes, enable the option to deploy processes and flows as active. This option applies to processes and autolaunched flows that are deployed via change sets and Metadata API.

In short, this means that to deploy a new version of a flow as an active version:

  • Non-production org:

    • No additional setup is required. The new version will be deployed as active.

  • Production orgs:

    • If deploy processes and flows as active is enabled

      • And the flow meets the code coverage requirement

        • Salto will deploy the new version as an active version

      • If the flow doesn’t meet the code coverage requirement

        • The deployment will fail

    • If deploy processes and flows as active is NOT enabled

      • Salto will deploy an inactive version

      • Salto will inform you that you must manually activate this version via the Salesforce UI

Pro tip: If you want to bypass this limitation and always deploy new versions as active to a production org, enable to deploy processes and flows as active setting and set the Flow Test Coverage Percentage field to 0

Deleting / Deactivating Flows

Deletions and deactivations of flows is not supported due to Salesforce API limitations.

Deployment Preview Errors

Based on the information above, we have enabled different deployment preview errors to help you avoid unsupported scenarios or to warn you about the possible outcome of deploying a flow.

For example, you may see some of these deployment preview errors:

Activating this flow will work in case of sufficient test coverage as defined in your salesforce org config.

Deploying these changes will create a new active version of this flow in case the test coverage percentage is greater than the number specified in your salesforce org config. Otherwise, a new inactive version of this flow will be created.

Deactivating a flow is not supported via metadata API.

Bear in mind that the new inactive version will not appear in Salto since your Salto environment is configured to prefer fetching active flow versions. }

Deploying these changes will create a new active/inactive version of this flow.

Use the information from this article to understand how Salto manages Salesforce flows. That should give you enough context to understand the deployment preview error.

Did this answer your question?