Within the Salesforce Triggers and Order of Execution documentation, the Save step is listed as:

  • Saves the record to the database, but doesn't commit yet.

What happens when a record is saved? Is a Salesforce ID and autonumber (if applicable) assigned? At which step are formula fields calculated? What is the difference between this step and the commit step listed below?

  • Commits all DML operations to the database.

3 Answers 3


A save writes your changes to the database, however at this point these changes are only visible to you within your transaction scope. The database has also generated undo information which contains the old values of your transaction which can be used to rollback your modifications.

A commit ends the current transaction and makes permanent all changes performed in the transaction. The transaction is a sequence of SQL statements that the database treats as a single unit. A commit also erases all savepoints in the transaction and releases transaction locks. After your data is committed, it is visible to other users of the system.

  1. What happens when a record is saved?
    • Your data is stored and can still be rolled back to its previous values.
  2. Is a Salesforce ID and autonumber (if applicable) assigned?
    • Yes
  3. At which step are formula fields calculated?
    • Formulas are calculated when the data is read, not when it is written.
  • 1
    Are formula fields calculated when queried as well, then? (Such as: select formula_field__c from Account)
    – Matt K
    Jun 16, 2015 at 16:17
  • 5
    Yes. That's what I meant by 'when the data is read'. When you demand a formula field's value, the value is calculated and shown to you on the fly. It is not stored on the record.
    – Mark Pond
    Jun 16, 2015 at 16:23
  • Great to know! Thank you for your thorough answer.
    – Matt K
    Jun 16, 2015 at 16:27

I don't know exactly if this is applicable to Salesforce, but I believe the difference is that the data is saved when the trigger is running (Save to Database), and then, when the Trigger enters the "finish" status, it commits these changes (saves) to the Database.

In a similar way, when working with a file in a git repository, if you save the file, git won't track the changes you made until you commit them (the file is saved locally, but not committed).


I think a good analogy here is shopping (whether ringing up items at your local convenience store with an old-timey cash register or paper receipt, or a modern digital checkout experience that saves all items digitally in your "cart" before checkout). Each generates a running list of items and subtotal as each item is scanned/added ("saved"). Let's say you change your mind halfway through checkout, and decide not to buy anything after all, because things you thought were on sale weren't after all (now the cashier voids the transaction and rips the half-finished paper receipt out, angrily no doubt--damn, those obnoxious "validation errors"!--and throws it in the trash). Or you get interrupted shopping online and some items stay in your "digital cart" until you come back at some time to actually finish checking out. Only after you finish ringing everything up, pay, and get handed/emailed a receipt, has the transaction actually occurred ("committed"). Prior to that, you couldn't leave the store or bring your stuff back later for a return, because you never actually finished checking out.

Or as another example, let's say only 1 thing rang up the wrong price. So the cashier corrects the price manually after you complain during checkout, based on some instructions from you ("trigger"), but only for your transaction (the next poor sucker will still pay the same mis-advertised price, unless they also ask for it to be fixed/changed in their transaction). There is your "before save" trigger or flow--and execution takes place in the context of the current operation only--updating only that specific record being saved before it is committed.

Only once you've completed your order and paid, is the transaction now complete. Now any subsequent actions that happen later (e.g. return one item for a refund) can occur based on the fact that you committed the final action of actually completing your purchase, checking out, and being handed/emailed your final receipt.

(And the Amazon Return counter at Kohl's is your giant Recycle Bin, where everything you just committed to can get undone! Haha)

Hmmm, is it obvious what I just spent some time doing today? ;)

You must log in to answer this question.

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