1

I am a bit confused lately regarding the order of execution of multiple updates:

Consider the following scenario:

  • I have Three Records: A and B and C
  • A fires an after update trigger that updates record B
  • B has an after update trigger that updates a record c
  • I update record A

Can someone please clarify the following questions for me?

  1. Do all the DML all occur in one synchronous transaction (i.e, one thread)
  2. Based on the Salesforce Order of Execution, Step 8 says: 'Execute all After Triggers'. When the After Update trigger gets to the line that says update b; What happens next?.. Is Step 1 executed for Record B OR is step 9-20 occur for record A and then the order of execution begins again for record b and the same behaviour for record C?
  3. if an error occurs at record B (i.e, a validation rule). Will record A still be updated? Or will the whole operation roll back?

I have looked at other similar questions like this, but nothing I have found really answers the entirety of my question. Thank you in advance for your help clarifying!

3

The order of execution is done serially, with each database operation kicking off its own "subtransaction" (for lack of a better word).

I'll be assuming that all records are for a single SObject, just for simplicity.

In your case, you start by updating record A.

  • System validation is run
  • Before trigger(s) for the SObject that record A is for are run
  • System and user-defined validation rules are run
  • etc...

Then, let's say you have an update for record B in an after update trigger (which would be the appropriate place for it seeing as record B isn't in the trigger context variables).

The trigger (and order of execution) for record B kicks off immediately. The trigger for record A does not progress until the "subtransaction" for record B completes.

In the end, the sequence of execution looks something like this:

  • Steps 1 - 7 are executed for record A
  • We start executing step 8 (after triggers) for record A, and then insert/update/delete record B
    • Steps 1 - 7 are executed for record B
    • We start executing step 8 (after triggers) for record B, and then insert/update/delete record C
      • Steps 1 - 21 are executed for record C
    • Now that we're done with record C, we resume step 8 (the after trigger) for record B
    • Steps 9 - 21 for record B are executed
  • Now that we're done with record B, we resume step 8 (the after trigger) for record A
  • Steps 9 - 21 are executed for record A

All of this counts as a single transaction, and governor limits are applied to the overall transaction. I would really try to stay away from the supposition that transaction = thread/process. That level of detail isn't relevant to us as users of the platform.

A failure at any point in the transaction causes the entire transaction to fail and be rolled back (unless you can handle/are handling exceptions).

5
  • What about step 20 / 21, in the example above, lets say A throws an uncaught exception at step 13. Would B and C would have been committed to the db (Step 20)? If I had post-commit logic for record C like sending an email, would the email be sent? how can these two events be rolled back?
    – Z33dawg
    Feb 19 '20 at 5:20
  • @Z33dawg Can't say for certain, but I believe emails and the final commit are saved until the very end of the overall transaction. It may not be entirely accurate to think of things this way (it'd need someone from the product development team to confirm), but think of it like having an automatic Database.setSavePoint() and Database.rollback() surrounding the entire transaction (the state prior to the transaction is known, and can be restored upon error).
    – Derek F
    Feb 20 '20 at 0:47
  • Thanks, got it. Last question for you: you said assuming that this would be for the same sObjects for simplicity. Would anything change regarding your answer should the trigger perform DML on a different Object?
    – Z33dawg
    Feb 20 '20 at 15:18
  • @Z33dawg I just wanted to avoid needing to write out "record A on object X", as I thought that would needlessly muddle the point I was trying to make. Involving more objects just makes the transaction harder to write out (Object Y could have workflow or processes that run that could cause update triggers to run again, it could be part of a master-detail with a rollup on the master which would cause the master object to undergo another save procedure mid-way, etc...) The overall premise I laid out still applies just the same.
    – Derek F
    Feb 20 '20 at 16:06
  • got it. thanks for the help!
    – Z33dawg
    Feb 20 '20 at 16:08
2

Do all the DML all occur in one synchronous transaction (i.e, one thread)

Yes, although "thread" is not a particularly useful concept to apply here - the most relevant boundary is that of the transaction, and the fact that it is a synchronous transaction.

Based on the Salesforce Order of Execution, Step 8 says: 'Execute all After Triggers'. When the After Update trigger gets to the line that says update b; What happens next?.. Is Step 1 executed for Record B OR is step 9-20 occur for record A and then the order of execution begins again for record b and the same behaviour for record C?

Step 1 is executed for Record B. Any recursive DML fired by Record B's automation will similarly be run to completion prior to ending the order of execution for Record B itself.

Note that an update statement would take place within an after trigger. The remaining logic of that after trigger may be dependent upon the record update for B, and all logic downstream of that update, completing successfully.

if an error occurs at record B (i.e, a validation rule). Will record A still be updated? Or will the whole operation roll back?

Unhandled exceptions, including validation rule failures leading to a DmlException, result in the rollback of the entire transaction.

The exceptions, pun intentional, are when you use partial-success methods in the Database class with allOrNone set to false:

Database.update(someSobjects, false);

or when you catch and handle the exception. Both situations don't result in an unhandled exception and a rollback.

2
  • Thank you! Can you clarify the difference between a thread and a transaction? I had been using them somewhat interchangeably. What is an example of a thread in the context of Salesforce?
    – Z33dawg
    Feb 19 '20 at 5:26
  • Threads are not exposed to on-platform implementors in Salesforce and they are usually not a useful conceptual framework to apply. Instead, think in terms of transactions, which may occur in parallel with one another, and the various forms of Asynchronous Apex available for on-platform development. A thread and a transaction are not equivalent.
    – David Reed
    Feb 19 '20 at 14:27

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.