Please don't try and deploy 'changed' Process builder processes.
Process Builder Flow versions appear as separate elements for deployment. Unfortunately you can't re-deploy an existing Flow, it won't let you change it, so Gearset shouldn't suggest that as an option.
The latest release of Gearset includes additional dependency analyzers which should automatically find and resolve the issues around deploying flows. This includes detection of active flows, flow definitions, and deletions of flow definitions.
My colleague Matt has emailed you with a more detailed summary of what’s changed.
Jason.
-
Sure Wes. We're planning on writing a blog post next week to explain this in more detail. In the interim, here's the info:
Our problem analyzer now detects a bunch of new things and gives you warnings / fixes pre-deployment.
We now detect if you're trying to deploy a change to (or deletion of) an active flow, or a change to an obsolete flow and offer to automatically remove it from the deployment package.
We also detect attempts to try to deploy new flow definitions without a version of the flow. We don't offer to fix this one automatically (because we don't know which versions of the flow you want to deploy and it felt presumptuous to pick one), unless the flow definition references a specific version of the flow.
We've added an analyzer to detect attempts to deploy a flow definition that references a version of the flow that won't be present in the target after the deployment (e.g. you set `NiceFlow-4.flow` active on source, and then forget to deploy `NiceFlow-4.flow` when attempting to deploy `NiceFlow.flowDefinition`), and offer to automatically include the dependency in the deployment.
Finally, we now warn on attempt to delete a flow definition and offer to remove those deletions from the deployment package.
-
Wes Weingartner commented
@jason, can the more detailed summary be included here? I'm interested in that. I was avoiding flows before.