CPU issues caused by process builder and workflows has really gotten bad in last 3 releases

Question

Not getting much activity on the Salesforce Community site with this one so I'll try it here. I've noticed a massive spike in CPU exceeded limits since Summer 15' and Winter 16'. I've personally looked into the debug logs for about 10 of these (at customer sites) and it seems like the process builder, and workflows allows the end user to build processes that exceed the CPU limits and the first trigger hit after the workflow throws the exception. It doesn't matter if there is just a single line of code in the trigger to get/set a variable - it just throws the exception.

In my case it is a managed package. I can uninstall my package and the next package in line hits the limits on entrance.

From everything I can tell it is like the process builder and visual workflows are allowing people to build what ends up being very poorly written code behind the scenes (crazy recursion etc) and not respecting the CPU limits (stuff you could not get away with in actual code without hitting a CPU limit exception) then upon exit all of a sudden any custom trigger or code pays the price.

Example from the logs:

Exit workflows - message Maximum CPU time: 17895 out of 10000 ******* CLOSE TO LIMIT Enter managed package - set one single variable - just a boolean CPU limit exceeded

Last time I checked that should have thrown an exception before it got down the chain any further (it is 7.8 seconds over the line). So is Salesforce just exempting the users from the limits in Process Builder and Workflows? If so that makes life hard for anyone else after those processes complete. i.e. any managed package or custom code.

My thought is that Salesforce should in fact throw an exception rather than kicking it down the line.

Answer 1

Edit: I was reminded of this question recently, and decided to make an edit. the original is left below for posterity.

---

After the original answer, I had the Flow Product Manager reach out to me. We had a nice conversation, discussed the future of Flows, and I had some suggestions that did eventually make it in to the Flow engine. Overall, I was very pleased with the outcome of that meeting.

Years later, Flows are now vastly improved, and features like Before Save Flows can perform almost as well as before DML triggers. They still don't cover every use case, but at least they can be considered viable for small-to-medium-sized orgs that can't afford dedicated or consultant resources.

And, as we all know, there are still more Flow enhancements scheduled out over the next few releases, so maybe finally we'll be able to scale Flows up to the point where Apex dependency is greatly diminished for these sorts of tasks.

---

The real problem is that the Process Builder uses CPU time. Given all of the other limits placed on flows, Salesforce shouldn't be counting execution of flows towards the total CPU time. Flows are notoriously slower than most hand-written code, except, of course, for that triple-nested for loop that every developer writes at least once. This idea suggests that people are still complaining about CPU time, even after this idea was delivered.

Internally, at our organization, we've had flows built that we later simply wrote up as Visualforce pages; we have basically disavowed Flows until they are proven to be better, which we expect will probably not be before Summer '17, considering what we know about the roadmap. Our re-written Visualforce pages were much faster, more user friendly, looked a lot closer to the actual look and feel of Salesforce's UX, and supported dynamic changes without users having to keep clicking Next all the time. In other words, Flow feels like it's some sort of hack rather than an elegant point-and-click solution to solving simple problems in configuration without code.

In fact, almost anyone that has a serious implementation of Salesforce doesn't have time to play around with flows right now. They're simply not practical. Salesforce needs to either not count flows, process builder, etc, against CPU time, or needs to be optimized to near the same level as what it would be if a developer took the time to write a trigger. While I realize that not every organization can afford developers, etc, I'm pretty sure the only way to keep things civil at the point is to recommend using non process-builder alternatives, such as workflow rules, triggers, Visualforce pages and/or Lightning components, etc.

Answer 2

Unlike the SOQL query governor limit, which is a hard limit, the CPU governor limit can be a bit squishy.

If the pod that your code (via your clients) is executing on isn't seeing too much demand at a given time, Salesforce can allow a transaction to run over the 10,000 ms limit.

The thing is that Salesforce only guarantees that you will have 10,000 ms per transaction. They (Salesforce) can cut off any transaction at any point after that.

Running over the CPU limit sounds like a sign of poor design, modeling, or execution on the part of your clients. Perhaps your package is resource hungry, and could stand to be improved. It's hard to say without looking at code. You just happen to be the unlucky package that's running in these instances when Salesforce decides to put their foot down.