Im working with one of our vendors who has a managed package installed in our org. They are currently using an @future method in the before context of a trigger on the Account object. We are investigating whether that setup is causing "Apex CPU time limit exceeded" errors when other processes try to update records in the Account object.

My concern is whether the @future in the before is locking the record and preventing the after context methods from completing in 60 seconds. If the @future is updating the same record as the trigger, shouldn't that be done in the AFTER context? Shouldn't any @future method be called from the AFTER and not BEFORE?

All input is appreciated. Thank you for your time.


No, calling future methods in a before trigger won't cause Apex CPU timeout errors. And, the rule of thumb about "validation and self-updates in before triggers, cascading and recursive updates in after triggers" is just that, a rule of thumb, or guideline. There are certainly exceptions to the rule.

Future methods do not run until after a transaction completes, including any after triggers, Flows, and Processes have run. They do not inherently cause some sort of lock that prevents the rest of the current transaction from completing, and locks on a record apply to a transaction, not any sub-step within the transaction.

I would say that it'd be unusual to call a future method for records in a before insert trigger, if only because you don't have record Ids to work at that point. However, whatever problem you're having is not related to these future methods. You'll need to do some profiling/debugging to figure out where the problem is.

  • Got it - thank you! – user891859 Oct 14 '20 at 14:11

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.