You need to sign in to do that
Don't have an account?
Jack Volkov
How can 2 versions of a process builder flow be merged?
Assume the following:
Developer sandbox A: process builder flow version 1 + version 2 (active version) with new changes
Developer sandbox B: process builder flow version 1 + version 2 with new changes + version 3 (active version) with new changes
Version 1 is the same in both sandboxes
Version 2 is different in both sandboxes
How can version 2 & 3 be merged together to create a new version that includes differences in both without overwriting anything?
Can source control be used some how for this?
Developer sandbox A: process builder flow version 1 + version 2 (active version) with new changes
Developer sandbox B: process builder flow version 1 + version 2 with new changes + version 3 (active version) with new changes
Version 1 is the same in both sandboxes
Version 2 is different in both sandboxes
How can version 2 & 3 be merged together to create a new version that includes differences in both without overwriting anything?
Can source control be used some how for this?
The two flows can be exported in a XML format. You can try to merge the xml files (extremely risky and very unlikely) and reimport them.
The best (only) solution is still the manual one if you don't have a ready java program for manipulating the metadata of the flows with the tooling api.
You will spend much more time with a very unlikely result manipulating the exportedf XML files instead of redoing the all thing manually but you can try (each time, I tried this kind of manipulation directly inside the xml file the result was an error or very unlikely).
That could work for very "simple" changes perhaps but here you have probably two big flows and you don't want to read/recreate each parameter of each node.
I often manipulate the metadata with java (never done with the flows until now), with the SF tooling api or the Andrew Fawcett's tool but this solution is interesting if you have dozens of flows to merge because the fine tuning is difficult and the return on investment could remain interesting.
The XML files of the flows are explained here (sample at the bottom of the page):
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm
Regards
We're going to try building process builder flows in a single sandbox org per flow. This way if there is version 1 and 2, if developer Bob wants to create another version, and developer Jill wants to create another version around the same time, Jill is at least aware of Bob's new version and can clone that so Bob's work is not lost or overwritten.
WARNING (documentation): Don't edit the metadata of retrieved Process Builder processes (Flow components whose processType is Workflow or InvocableProcess.) If you deploy process metadata that you've edited, you might not be able to open the process in the target org.
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm
You can try nevertheless. Not supported at all by Salesforce (extremely risky and very unlikely) but you can be cleverer than the others.
I manipulated XML definitions for ETL for instance and that work fine but that were just mappings.
Here the actions are complicated and that could be destructive for your flows (you will lose everything).
Regards