I have a Process Builder Rule that looks for a change to a user lookup field on the Account. When it's changed, it reassigns every Contact within that Account to be owned by the new user. Problem is that when the Account contains more than ~200 Contacts, I get hit with a CPU limit error.

Would this be better served as a trigger? I should note that I set this up as a PBR to begin with because I'm pretty terrible at Apex.

2 Answers 2


Unfortunately, your only resort may indeed be a trigger. Process Builder is great for simple updates to the currently executing record, or one of its parents, but can't really do mass updates well. There's plenty of examples of how to do this on the Internet (including this site) already; it's a pretty basic requirement, and there's even an Idea for this (go vote now; I'll wait). I've also recently written an answer that basically explains how you'd do this, but it does require some thinking to complete the trigger. If you get stuck, do feel free to ask your own questions, or peruse our questions for assistance.

  • Looks like that idea is coming with the 17 Spring release -- the only problem is that I want Contact owners synced to a different user lookup than Account Owner. I'll give the trigger a shot -- thanks!
    – Matt
    Commented Apr 22, 2017 at 21:43
  • I was able to get this into trigger form, but I still hit CPU limits (in sandbox) if the account has > 600 contacts. Is there any way to get around this, or does it require cleaning up other processes running at the same time?
    – Matt
    Commented May 2, 2017 at 22:08
  • @Matt You'll have to use Profiling to figure out how to fix it. Everything is cumulative. If you go in your Developer Console, you can change your debug log levels so that PROFILING is set to FINEST. This should tell you where your problem lies.
    – sfdcfox
    Commented May 2, 2017 at 22:13
  • Is there a general limit I should keep in mind for this? Meaning, should you be able to process thousands of changes before hitting the CPU limit? 10s of thousands?
    – Matt
    Commented May 2, 2017 at 23:17

A quick and dirty fix could be to throw the update into a scheduled action in pb. Downside is that it wouldn't be immediate, but it could get you some additional breathing room. Not positive in the CPU time limit case, but generally it can handle more in a scheduled action.

An intermediate approach could be to try visual workflow, as you could design a counter that would increment and throw the remainder to a wait element if the number approaches the limit

That said PB, with all its limitations around bulkification, shouldl be able to update 200 records without hitting cpu time limit. I wonder what else is happening on contact or account that might be contributing.

In the end a trigger is by far the best option, but you might want to try to see if you can get a bit further before going there, and if other stuff you have going on is contributing to the CPU time issue, you may find that pops up w triggers as well.

You must log in to answer this question.

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