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
Although it is possible to use
Is changedin the process builder to see if the record or field was changed, if you want to get the old record, like you would in a trigger context, I recommend using a variable in your flow to pass the old values as needed.For example, if you need the opportunity's picklist field
StageNamein a flow, because you have multiple steps and you want to do different logic based on the previous step, you can adjust your flow to receive the old value as a variable using a formula on the field, likePRIORVALUE(StageName).This way, if your flow has a record input, you'd also have a string input for that old value.
Now, as for what "best practices" say, that will depend on your solution. Is this logic big or does it take a good amount of time to process? If so, then you might face issues when processing lots of records at once. If that happens, moving the logic to Apex would be the best practice, I think.