The following is the order of salesforce execution when the you create or update a record,
1) Loads the original record from the database or initializes the record for an upsert statement.
2) 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:
Required values at the layout level and field-definition level
Valid field formats (ex: zip code, country code format)
Maximum field length (ex: mobile number must 10 digits)
Salesforce doesn’t perform system validation in this step when the request comes from other sources, such as an Apex application or a SOAP API call.
3) Run all before triggers.
4) 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.
5) Saves the record to the database, but doesn’t commit yet.
6) Run all after triggers.
7) Run assignment rules.
8) Run auto-response rules.
9) Run workflow rules.
10) If there are workflow field updates, updates the record again.
11) If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.
12) Run escalation rules.
13) 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.
14) If the parent record is updated, and a grand-parent 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. Grand-parent record goes through save procedure.
15) Run Criteria Based Sharing evaluation.
16) Commits all DML operations to the database.
17) Run post-commit logic, such as sending email.
1) Loads the original record from the database or initializes the record for an upsert statement.
2) 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:
Required values at the layout level and field-definition level
Valid field formats (ex: zip code, country code format)
Maximum field length (ex: mobile number must 10 digits)
Salesforce doesn’t perform system validation in this step when the request comes from other sources, such as an Apex application or a SOAP API call.
3) Run all before triggers.
4) 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.
5) Saves the record to the database, but doesn’t commit yet.
6) Run all after triggers.
7) Run assignment rules.
8) Run auto-response rules.
9) Run workflow rules.
10) If there are workflow field updates, updates the record again.
11) If the record was updated with workflow field updates, fires before and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.
12) Run escalation rules.
13) 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.
14) If the parent record is updated, and a grand-parent 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. Grand-parent record goes through save procedure.
15) Run Criteria Based Sharing evaluation.
16) Commits all DML operations to the database.
17) Run post-commit logic, such as sending email.
No comments:
Post a Comment