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.

  • Kind of shocking you've been blogging for so long but this is only your second post!
    – Adrian Larson
    Commented Aug 15, 2016 at 15:04
  • 2
    We are still telling our customers to not use process builder as it causes a lot of support calls to us when we are not the source of the problem and more importantly the inability of PB to fail gracefully and prevent records from being inserted / saved. In a business critical component this simply cannot be allowed. We Also found that PB was not executing in bulk. Bulk operations involved separate DML operations for EACH record....Not sure if that is still the case or not. Either way PB is not ready for prime time
    – Eric
    Commented Aug 15, 2016 at 15:39
  • Worse yet, the profile information in the debug logs does not show where the CPU time is actually being used in cases where there are managed packages involved. All the CPU time is attributed to the org itself. So yes, what you are seeing is a real thing and a real problem.
    – kibitzer
    Commented Aug 15, 2016 at 17:14

2 Answers 2


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.

  • I haven't used flows yet myself, so I didn't realize that their performance was abysmal. As a side note, converting flows into Visualforce (or rather, using Visualforce to emulate flows) sounds like an excellent idea for a blog post (wink, wink, nudge).
    – Derek F
    Commented Aug 15, 2016 at 16:13
  • nice to hear this -- I find flows to be opaque when diagnosing/discovering -- it is not obvious what they do when you look at the flow UI; lots of clicking and inspecting.
    – cropredy
    Commented Aug 15, 2016 at 22:44

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.

  • Hahaaa. This is essentially the conclusion that I came too as well. 100% in agreement - in all cases that I have reviewed, there is so much going on with these customers in terms of Workflows/Processes that when they do bulk operations like import/update it just dies mid stream and blames the unlucky code (as you said) that comes next. Commented Aug 15, 2016 at 13:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .