Triggers and Order of Execution

Triggers and Order of Execution

  When user Save record with insert, update or upsert statement in salesforce.com.

1. Client Side Execution:

• JavaScript validation
• Dependent pick list

2. Server side Execution:

• 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

   Salesforce does not perform system validation in this step when the request comes from other sources, such as an Apex application or a Web services API call.

• 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 does not run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
• Saves the record to the database, but does not 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 and after triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.
• Executes escalation 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 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.
• Executes Criteria Based Sharing evaluation.
• Commits all DML operations to the database.
• Executes post-commit logic, such as sending email.

*Note: During a recursive save, Salesforce skips steps 7 through 14.

Additional Considerations

Additional Considerations:

Please note the following when working with triggers:

    * When Enable Validation and Triggers from Lead Convert is selected, if the lead conversion creates an opportunity and the opportunity has Apex before triggers associated with it, the triggers run immediately after the opportunity is created, before the opportunity contact role is created. For more information, see “Customizing Lead Settings” in the Salesforce online help.

   * If you are using before triggers to set Stage and Forecast Category for an opportunity record, the behavior is as follows:

          o If you set Stage and Forecast Category, the opportunity record contains those exact values.

          o If you set Stage but not Forecast Category, the Forecast Category value on the opportunity record defaults to the one associated with trigger Stage.

          o 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:

         1. The parent opportunity is saved according to the list of events shown above.

         2. The opportunity products are saved according to the list of events shown above.