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!

Improve this question

2 Answers 2

Reset to default
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).

Improve this answer
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
    Commented Feb 19, 2020 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
    Commented Feb 20, 2020 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
    Commented Feb 20, 2020 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
    Commented Feb 20, 2020 at 16:06
  • got it. thanks for the help!
    – Z33dawg
    Commented Feb 20, 2020 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.

Improve this answer
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
    Commented Feb 19, 2020 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
    Commented Feb 19, 2020 at 14:27

You must log in to answer this question.

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