I think so and I'm wondering if others have seen similar issues. Our org has nightly job, very simple code, just updates Contact records if it meets simple criteria. It's been running for months every night with no issues

We recently started "playing around" with Process flows. Seems like SF is moving in that direction, so we should start getting used to them. However, recently, that nightly job is blowing up APEX CPU limits. Was never had an issue before. So in execute anonymous mode, opened up a debug, and the debug log looks like that ONE process flow is eating up about 5-7 seconds of the entire job.

The process flow is very simple too: ISCHANGED(Field1) && ISPICKVAL(FIELD2) then Update some other field. None of the records meet those criteria, so there's no updates - just the simple testing of whether to run the process is eating up the limit.

We have half a dozen validation rules and about a dozen workflow rules on the contact object already, some are MUCH more complicated than this one process flow (the only one running in our org right now).

I'm getting ready to convert the process flow over to an old workflow rule, but before doing so, wanted to see if others had other suggestions.

Here's a snippet from the debug code (edited for privacy) and you can see that each process flow test is taking up .003 seconds. Seems like not a lot, but over a group of big records, it adds up really quickly!

 17:16:06.441 (4441673953)|WF_FLOW_ACTION_BEGIN|x
17:16:06.441 (4441740750)|FLOW_CREATE_INTERVIEW_BEGIN|xxxxx|xxxx|xxxx
17:16:06.441 (4441784137)|FLOW_CREATE_INTERVIEW_END|xxxxxe-bb24|UpdateCurrentProcessorSwitchedDate
17:16:06.444 (4444543492)|WF_FLOW_ACTION_BEGIN|xxxx
17:16:06.444 (4444611074)|FLOW_CREATE_INTERVIEW_BEGIN|xxxxx|xxxxx|xxxxxx
17:16:06.444 (4444650150)|FLOW_CREATE_INTERVIEW_END|xxxxxxx-bb23|UpdateCurrentProcessorSwitchedDate
17:16:06.447 (4447420559)|WF_FLOW_ACTION_BEGIN|xxxx
17:16:06.447 (4447487820)|FLOW_CREATE_INTERVIEW_BEGIN|xxxx|xxxxxxx|xxxx
17:16:06.447 (4447526856)|FLOW_CREATE_INTERVIEW_END|xxxxxxx-bb22|UpdateCurrentProcessorSwitchedDate

This is likely due to Process Builder not yet bulkified (and you can upvote the Idea here: https://success.salesforce.com/ideaView?id=08730000000DhBlAAK). This would mean the process is being run in sequence for each record (and indeed, your log seems to confirm it) instead of workflow rules running in parallel batches.

| improve this answer | |
  • 1
    I basically fell out of my chair when I read this. Totally heartbreaking and after some additional research, turns out to be true! What's heartbreaking about it is that even if the Process criteria are not met, it still causes the cpu time limit to be exceeded, which basically means you can't use process builder or visual workflow on ANY OBJECT that experiences bulk uploads, even if those flows won't be implicated by the bulk upload! – StartingAgain Jul 19 '15 at 18:27
  • Yep. It's not a great scene. I recommend upvoting the issue and commenting about your specific problem. There has been a lot of discussion about SOQL limits hit with Process Builder but not as much about CPU limits, so it's worth getting that in the brains of the platform folk too. As an aside, has changing your batch size affected performance at all? – Christian Carter Jul 19 '15 at 18:51
  • I can try that and it would most likely work. What is best practice here though? Currently ~850 records implicated. This is nightly job (1am) that needs to finish, so would we limit to 250 and then schedule the same class to run 10 mins later and then another to run 10 mins later etc. Also think we can make this asynch (use at @future tag) to help things along... – StartingAgain Jul 20 '15 at 5:11
  • I don't think there is a best practice here, you seem to be charting new (or at least, unblogged-about) waters. Scheduling a pile of tasks 10 minutes apart seems...not ideal but I suppose it would work. I think in this case it may be more productive to move to a well tested trigger instead of a Process. – Christian Carter Jul 20 '15 at 5:46
  • Great, thanks, I think I'll post a new question on how to make the code more efficient and go from there, thanks again for the help – StartingAgain Jul 20 '15 at 18:59

I've been watching this one since last summer and I was really hoping to see improvement when they rolled out the fix in Winter 16'. Here is the behavior that I am seeing as an ISV - customers are using process builder and by the time the workflows are done - the first trigger hit throws a CPU limit exception. Incidentally the first line in the trigger is a check to see if the context is anywhere near 90% CPU usage and then it just has a return statement. The problem is it can't even execute that line. It can't even pull a value from the managed package settings which are cached. I would say that the number of these has gone up x10-12 times since the last two releases.

These are customers so we can tell them they went nuts with workflows and processes but that doesn't solve the problem for either of us.

| improve this answer | |
  • Yup, I agree. People say this has been solved - but it hasn't. if you follow the feature tracker, the PM actually says they've closed this issue out and he/she essentially admits that they handle process workflows differently than traditional workflow rules. Maybe one idea is to change the triggers you have written to process workflow? and then if it blows up you can tell salesforce and see what they say? – StartingAgain Jul 26 '16 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.