[SalesForce] Deployment issues with Process Builder Flows

Deploying Process Builder Flows from one org to a target org only works via the ant migration tool if the existing process builder flows are deleted first using destructive changes. However, if the destructive changes take place and the subsequently deployment breaks for any reason then the target org remains in a state where the flows no longer exist.

In general, the deployment of the flows presents some challenges.

  1. The flows will only deploy in deactivated mode in the target org by default. They have to be manually activated in the target org after deployment.

  2. Once they are activated in the target org, any subsequent builds to the target org fail with the message that the flow(s) in the target org are active and cannot be overwritten. Deactivating them in the target org, does not seem to work. They have to be deleted before the next build in Version 33.0.

To summarize, the challenge is that if we do not delete the flows, any subsequent build to the org fails. If we do delete them, any build that fails ends up leaving the org with no flows.

Attempted solution:

Create entries in the destructiveChanges.xml to delete these flows. The subsequent build that occurs will recreate them. This solution is currently in place, but there are two issues with this: 1) If the build fails, then the destructive changes are not rolled back. The target org is therefore without the flows that it needs. 2) If the build is successful, the flows still have to be manually activated.

I investigated using version 34.0 and that still has the same issue even though it supports a FlowDefinition and activeVersionNumber metadata, it still runs into the same issue. The existing flows even if they are not active prevent subsequent deployments.

Best Answer

There are some goodies in version 34.0 that should help you out. As you already noticed 196 added the concept of FlowDefinition that should allow you to activate/deactivate processes (flows) via the MD API. 196 also solve the problems around continuous integration by adding a permission you can turn on: FlowMdOverwriteEnabled. Flip this perm on and you will be able to overwrite active versions as well.

For anyone reading this post: Use this perm carefully because it will bypass every guard we have put in place to accidentally avoid overwriting an active process/flow.

Update:

The permission to request on the Case you raise is Enable MD Deploy to overwrite flows.

Related Topic