I'll give this one a shot.
disclaimer: The only experience I have with process builder was helping my boss out in the Dev Zone at Dreamforce last year.
Process Builder is a tool that sits in between workflow and Apex in terms of what it can accomplish. Process Builder can be the best fit for the task at hand, but like all tools, it can be misused.
The big advantage to Process Builder is that it gives you a sizable portion of the power of Apex code without the need to actually write Apex code. You just need to have a somewhat programmer-ish mindset (knowing how to make use of loops, variables, and conditionals).
Having even a single developer on staff can be a big investment for a company. Process Builder allows some of the benefit of a dev, without the full cost of a dev. It saves money...for a time.
I'd argue that using Process Builder means that you start to accrue considerable Technical Debt. The numerous downsides that you mention are all technical debt.
The scenario you describe sounds like someone has (or several people have) succumbed to the Law of the Instrument, which, restated, is
When you have a golden hammer, every problem starts to look like a nail
Process Builder helped them out on problems x and y, so it should work for problem z too, right?
Well, after some ill-defined point, the processes start getting more complex. They also start to become more tightly coupled, and interact with one another more and more.
In your situation, it sounds like there's an issue of shared resource planning as well. One business unit may not have/want a dev to take care of this, but it will end up impacting the rest of the business units.
It is at that point where I believe you cross the line in the sand where a developer writing Apex makes more sense. Some of the value of a Good Dev™ is that they are able to manage the interactions required between the business logic in a way that scales well, is easy to maintain, and is easy to extend.
The takeaway
Process Builder can be used to solve a variety of issues, but it isn't always the right tool and is no substitute for a competent developer.
The situations where I'd consider using Process Builder are:
- When you are only performing work on a single object
- You aren't trying to work on more than a hundred records or so
- The required logic isn't terribly complex (a couple of
ANDs and ORs at most)
- You can't afford to hire a dev right now, but will be able to in the near future (< 1 year)
Used correctly, Process Builder can serve as a replacement for simple triggers until your org needs to start considering code scaling. It even may be faster to develop than a trigger.
Moderately complex logic and interactions with other objects are a good way to quickly get over your head, and would require more up-front cost when a dev is brought in to untangle the unholy mess.
Best Answer
Only the ACTIVE version is pushed. Hope this helps! :)
Please review the documentation: https://help.salesforce.com/s/articleView?id=sf.flow_considerations_distribute_changeset.htm&type=5