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)?

Improve this question
9
  • What api version is your process flow?
    – Mohith Shrivastava
    Commented Jun 1, 2020 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
    Commented Jun 1, 2020 at 22:20
  • @phil push is available only in scratch orgs and recently sandboxes
    – Mohith Shrivastava
    Commented Jun 1, 2020 at 23:02
  • 1
    I am sure you are running into same situation as mine. Check this: salesforce.stackexchange.com/questions/298333
    – javanoob
    Commented Jun 2, 2020 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
    Commented Jun 2, 2020 at 7:29

8 Answers 8

Reset to default
5

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).

Improve this answer
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
    Commented Jun 3, 2020 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?
    – Ruslan Kurchenko
    Commented Sep 25, 2020 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
    Commented Sep 25, 2020 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
    Commented Jan 27, 2021 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.

Improve this answer
5
  • Welcome to SFSE!
    – David Reed
    Commented Aug 28, 2020 at 17:41
  • 1
    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.
    – Ruslan Kurchenko
    Commented Sep 25, 2020 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?
    – Timothy Peng
    Commented Oct 5, 2020 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
    Commented Jan 27, 2021 at 2:37
  • @TimothyPeng We are also experiencing this issue, we are not changing anything at flow but still getting trouble by this issue. Case No 42308320
    – Ankuli
    Commented Apr 20, 2022 at 6:35
2

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

Improve this answer
2
  • 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
    Commented Feb 11, 2021 at 0:29
  • This was helpful, thanks
    – Santanu Halder
    Commented May 5, 2023 at 7:50
1

@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.

Improve this answer
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.0 (the newest one at the moment) and deployed it a few times to the sandbox, no new flow versions appeared.

Improve this answer
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.

Improve this answer
0

Adding to the stack for this.

I did some testing in a scratch org, and thus far it seems no matter what I do, unless the metadata is set to <status>Draft</status> a new version is created in the target org.

Basically, whenever the metadata contains <status>Active</status> it creates a new version.

Improve this answer
0

We also ran into this issue while migrating a couple of flows and the issue for us ended up being a capitalization inconsistency in the object. It went overlooked since we had no issues deploying source to org in our development sandbox, and the flow was working as expected (up until we got the Maximum flow versions reached error). It wasn’t realized until we recreated the flows as was suggested in this stack, compared the file and saw the difference. We also noticed that retrieving source from org via SFDX: Deploy This Source to Org will update the metadata to resolve any capitalization inconsistencies without having to rebuild the flow manually. So if this issue arises after migrating a flow, update the apiVersion to align with your target environment as suggested above and retrieve source from org to handle any other inconsistencies (like capitalization) that may have been overlooked.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .