When you save a record with an
insert,
update, or
upsert
statement,
Salesforce performs the
following events in order.
On the server,
Salesforce:
- Loads the original record from the database or initializes the record for an upsert statement.
- Loads the new record field values from the request and overwrites the old values.
If
the request came from a standard UI edit page,
Salesforce runs system validation
to check the record for:
- Compliance with layout-specific rules
- Required values at the layout level and field-definition level
- Valid field formats
- Maximum field length
When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign
keys. Prior to executing a trigger, Salesforce verifies that any custom
foreign keys do not refer to the object itself.Salesforce runs user-defined validation
rules if multiline items were created, such as quote line items and opportunity line
items.
- Executes all before triggers.
- Runs most system validation steps again, such as verifying that all required fields have
a non-null value, and runs any user-defined
validation rules. The only system validation that Salesforce doesn't run a second time
(when the request comes from a standard UI edit page) is the enforcement of
layout-specific rules.
- Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and
uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.
- Saves the record to the database, but doesn't commit yet.
- Executes all after triggers.
- Executes assignment rules.
- Executes auto-response rules.
- Executes workflow rules.
- If there are workflow field updates, updates the record again.
- If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more
time), in addition to standard validations. Custom validation rules and duplicate rules
are not run again.
- Executes processes.
If there are workflow flow
triggers, executes the flows.
The Process Builder has superseded
flow trigger workflow actions, formerly available in a pilot program.
Organizations that are using flow trigger workflow actions can continue to
create and edit them, but flow trigger workflow actions aren’t available for new
organizations.
- Executes escalation rules.
- Executes entitlement rules.
- If the record contains a roll-up summary field or is part of a cross-object workflow,
performs calculations and updates the roll-up summary field in the parent record. Parent
record goes through save procedure.
- If the parent record is updated, and a grandparent record contains a roll-up summary
field or is part of a cross-object workflow, performs calculations and updates the roll-up
summary field in the grandparent record. Grandparent record goes through save
procedure.
- Executes Criteria Based Sharing evaluation.
- Commits all DML operations to the database.
- Executes post-commit logic, such as sending email.
Additional Considerations
Please note the following when working with triggers.
- The order of execution isn’t guaranteed when having multiple triggers for the
same object due to the same event. For example, if you have two before insert triggers for
Case, and a new Case record is inserted that fires the two triggers, the order in which
these triggers fire isn’t guaranteed.
- When a DML call is made with partial success allowed, more than one attempt can be made
to save the successful records if the initial attempt results in errors for some records.
For example, an error can occur for a record when a user-validation rule fails. Triggers
are fired during the first attempt and are fired again during subsequent attempts. Because
these trigger invocations are part of the same transaction, static class variables that
are accessed by the trigger aren't reset. DML calls allow partial success when you set the
allOrNone parameter of a Database DML method to false or when you call the SOAP API with default settings. For
more details, see Bulk DML Exception Handling.
-
If you are using
before
triggers to set
Stage and
Forecast Category
for an opportunity record, the behavior is as follows:
- If you set Stage and Forecast Category,
the opportunity record contains those exact values.
- If you set Stage but not Forecast
Category, the Forecast Category value on the
opportunity record defaults to the one associated with trigger
Stage.
- If you reset Stage to a value specified in an API call or incoming from
the user interface, the Forecast Category value should also
come from the API call
or user interface. If no value for Forecast Category is
specified and the incoming Stage is different than the trigger
Stage, the Forecast Category defaults to
the one associated with trigger Stage. If the trigger
Stage and incoming Stage are the same,
the Forecast Category is not defaulted.
- If you are cloning an opportunity with products, the following events occur in order:
- The parent opportunity is saved according to the list of events shown above.
- The opportunity products are saved according to the list of events shown above.
- Trigger.old
contains a version of the objects before the specific update that fired the trigger.
However, there is an exception. When a record is updated and subsequently triggers a
workflow rule field update, Trigger.old in the
last update trigger won’t contain the version of the object immediately prior to
the workflow update, but the object before the initial update was made. For example,
suppose an existing record has a number field with an initial value of 1. A user updates
this field to 10, and a workflow rule field update fires and increments it to 11. In the
update trigger that fires after the workflow field update, the field value of the object
obtained from Trigger.old is the original value
of 1, rather than 10, as would typically be the case.