7

We just started using VCS for all metadata changes for our orgs.

One problem we encountered is, that when we deploy changes to org via sfdx force:source:deploy, sometimes a new inactive Process Builder version is spawned, even though a Process Builder is not changed. It doesn't happen for every Process Builder, and it's not persistent sometimes a deployment spawns new version of PB every deployment, sometimes it doesnt. The problem results in hitting Maximum flow versions reached error.

Is there a best practice storing Process Builder in VCS(Git)?

9
  • What api version is your process flow? Jun 1 '20 at 20:08
  • I guess this is because you use deploy rather than push. If you use push then only changed metadata gets sent to the server. Can you switch to push instead of using deploy?
    – Phil W
    Jun 1 '20 at 22:20
  • @phil push is available only in scratch orgs and recently sandboxes Jun 1 '20 at 23:02
  • 1
    I am sure you are running into same situation as mine. Check this: salesforce.stackexchange.com/questions/298333
    – javanoob
    Jun 2 '20 at 0:06
  • @MohithShrivastava thanks for the added point about "push" compatibility - still, it might be an alternative depending on the type of org being deployed to.
    – Phil W
    Jun 2 '20 at 7:29
4

Is there a best practice storing Process Builder in VCS(Git)?

Ideally? Don't deploy Processes or Flows (same metadata type) to persistent orgs via Continuous Integration, because you will hit the limit sooner or later. If you use scratch orgs, they won't be affected, but the persistent org that is your metadata's ultimate destination will be.

If you are a Salesforce end user, you can probably fix the issue just by deleting old Flow versions (although there isn't a definite way to stop them from accumulating in the first place).

If you are an ISV using a 1GP packaging org, you won't be able to delete Flow versions that have been packaged, making this issue extremely serious for users of CI/CD. Additionally, each managed package version that's installed by your subscribers containing a new Flow versions accrues that version in their org, so 50 total upgrades will result in a non-upgradeable subscriber org.

I've discussed this issue with the Flow PM and engineering team (I work on managed packages at Salesforce.org) and they are evaluating ways to address it in the future (safe harbor, no timeline available at present).

4
  • Thanks for mentioning the issue with managed packages. I'm also working with one and it can be extremely frustrating if you hit one of these sudden roadblocks as they're no easy fixes for this (and sometimes even none at all).
    – Semmel
    Jun 3 '20 at 18:02
  • Thank you for the detailed explanation, especially for the 1GP use-case. We have the exact situation with Visual Flows and noticed that versions are generated for every flow on the subscriber org with no option to purge them. Did you get any update on this issue from Salesforce so far? Sep 25 '20 at 11:57
  • @RuslanKurchenko I'd suggest you file a Case and share the details with Timothy Peng (below) as his team are the wizards investigating the underlying issues.
    – David Reed
    Sep 25 '20 at 19:34
  • oh dear -- we just hit this in our CI (non scratch org). Options: One can refresh the CI org from PROD or mass delete Flow versions per this answer
    – cropredy
    Jan 27 '21 at 2:32
2

@ Curious Squirell, I am the Flow PM working with David & the .org team to find ways to resolve this. In most cases, if nothing's changed in the metadata, a deploy should not result in a new version creation. Are you still encountering this issue today? If so, please file a case & give me the case number so that we can investigate. Or, post in the Salesforce Automation group in the Trailblazer community and I can coordinate with you directly.

4
  • Welcome to SFSE!
    – David Reed
    Aug 28 '20 at 17:41
  • Any updates about the 1GP use-case? As far as I can see, even if the flow is not changed, the system generates a new version. Sep 25 '20 at 12:01
  • I haven't been able to connect with the curious squirrel. However, new versions should only be generated in a few cases ... + The MD has changed + The statuses are different + A new Flow feature is introduced which, even if not used immediately, causes changes in the metadata at save time (e.g. a new required field is added as part of a feature, and we auto-populate null values at save time if the customer doesn't use the feature) Ruslan, are you seeing duping occur that isn't related to the Status, and is reproducible multiple times in a row vs just once at a major release boundary? Oct 5 '20 at 19:47
  • we deploy from Git -> CI org but the metadata in Git has not kept up with new metadata tags introduced with new SFDC versions. So, the Metadata compare shows a diff and a new flow version is deployed (example <apiVersion>49.0</apiversion> was a tag added after we last committed the flow to GitHub
    – cropredy
    Jan 27 '21 at 2:37
1

We had noticed this as well and the issue for us was that the API version of the manifest or Flow didn't match the target environment. So the environment was making changes to the Flow each time it was deployed in order to update it to latest API version which was causing it to appear as a new Version

Specifically our metadata for our Flows was API 49.0, and we were deploying to an environment on API 50.0. The changes to Flow added in that version cased SF to make changes to the metadata each time it was deployed to update it to 50.0, causing a new version

1
  • This is much closer to the real answer. Changing the API Version of the flow will definitely create a new version, but I've still replicated several examples of new Flow versions being created even with the API Version staying exactly the same, matching the environment's API version, sfdx-project.json sourceApiVersion, etc.
    – Sam Howle
    Feb 11 '21 at 0:29
1

Thanks David for sharing your finding. We run into 'Maximum flow versions reached' sfdx deployment error too. It turned out that we didn't have any xx.0 line committed to our flow definition xml. That resulted in SFDC creating a new flow version each time we deployed it to a sandbox, no matter if there were some new changes to the flow or not. When I added 50.00 (the newest one at the moment) and deployed it a few times to the sandbox, no new flow versions appeared.

0

@David Dusing's response is much closer to the real answer.

Changing the Flow's Api version will definitely create a new version, but I still see new Flow versions created from deploying identical files (same Flow API version that also matches the environment's current API Version, and the SFDX json project file's API version). I believe it's related to when the Flow/PB was created and the specific metadata tags from that time. For example, if a PB was created during v40 it won't matter if you manually update that Flow to v51 because the metadata tags in that older era are different (but still compatible) to what's currently used.

This doesn't appear to be an issue for recently created flows. If you re-built your PB manually, retrieved to source, then it should resolve the issue (unless you make updates obviously). TBD if this issue will reset once future releases come out.

I don't care nearly as much about limits on Flow Versions as I do about version control. It becomes a problem when all of your PBs/Flows keep showing up as recently modified when they might not have changed in a year. Especially given the very spare details that Salesforce provides in the UI (no "Created By" or "Last Modified By" details). If I didn't know any better I'd think our org was updating process builders every week.

0

After also hitting this issue, this is what I found out after some experimenting, using VS Code:

With a Flow that was creating a new version on every deployment, retrieving the source with force:source:retrieve, with sfdx-project.json set to the latest api version, retrieved a modified .flow-meta.xml.

Comparing the before and after shows a new tag <apiVersion> and other small differences. The value of <apiVersion> is not necessarily the value in sfdx-project.json however, it is the value set for 'API version for running the process' in the Flow Properties (verified by changing it on an inactive Flow and retrieving again). <apiVersion> is not currently mentioned in the Flow entry in Metadata API Developer Guide.

Converting to metadata format and deploying this updated metadata creates one new version, but redeploying does not create any further versions.

If you're storing your code in metadata format, I would expect force:mdapi:retrieve to give the same result but have not tested it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.