We are an OEM provider and we have a 2GP package that we have developed over the years. We just tried to deploy a package to an environment and ran into a failure because of a limit on the number of flow versions. We have a flow that has 50 versions somehow and because of that we can't deploy our package anymore to that org unless we manually delete a version (I assume).
We looked into the flow that caused the issue and we have updated the flow xml metadata file once in the last 13 months (api version upgrade) and 4 times ever. Which leads me to ask why are flow versions for our flows being updated in every package that we create? What causes flow versions to be created?
This seems to be happening to every flow that we have packaged in the 2GP. When we make a new package and push to the environment we see a new flow version created. Even if the flow xml is not changed. Even if the new code changed is not related to the flow at all.
Here is a screenshot showing an example of all the version being changed and in this time frame we only made the one change to the flow xml metadata file - which was the version updated. Every other version of our package had no changes to the flow xml file.
Our Development Setup/Process:
- We build the package with the command:
sf package version create --package "<package name>" --installation-key <install-key> --code-coverage
- We push our package to all of our customers organizations using the PackagePushRequest object.
- Every customer organization is created using a TrialForce template that we create from our source org. We push the package there and then create a template from that we use to create customer orgs.
- We use Scratch orgs for doing development. When we create a scratch organization and push our code to it there is only one version of each flow in the scratch org.
Is this happening to anyone else?
What makes a new flow version be created in a 2GP?
Is there a way to delete older versions of a flow during the package installation process? Or through an API? I wouldn't want to clean these up manually..... for every org we have....
Salesforce often creates a new flow version during deployments, even when there are no visible changes in the flow's XML. This issue typically arises due to minor differences between the source and target environments, such as deprecated or auto-generated properties in the flow metadata.
Steps to Identify and Resolve the Issue:- Set Up a Clean Branch: Ensure your Git branch has no unstaged changes.
- Deploy the Problematic Flow: Use the following command to deploy the flow to a sandbox:
sf project deploy start -m Flow:Name_Of_The_Flow -o SANDBOX_NAME
Observe that the deployment result indicates a "Changed" status, and a new version is created.
- Retrieve the Flow from the Sandbox: Run the following command to pull the flow from the sandbox:
sf project retrieve start -m Flow:Name_Of_The_Flow -o SANDBOX_NAME
Check the retrieved XML for differences compared to your local version.
- Analyze the Differences: Look for minor discrepancies, such as:
- Deprecated properties (e.g., <migratedFromWorkflowRuleName>).
- Auto-generated metadata (e.g., locationX, locationY, or processMetadataValues).
- Re-deploy the Retrieved Version: Deploy the retrieved version back to the sandbox. If the deployment result now shows "Unchanged," the issue is resolved.
Hope this helps!