We can basically do five different operations on Salesforce records:

• Insert
• Update
• Upsert (which is just an insert or update operation, depending on the fact that the record may already be in the database, given a unique field such as its ID)
• Delete
• Undelete

While the delete and undelete operations have never been mentioned when we talked about automation (and this is one of the reasons Apex triggers are most suitable for certain scenarios), insert and update operations (and upsert) follow a determined order of events (which should become your mantra when designing automation) as follows:

1. The original record is loaded from the database (or a new record is initialized in case of insert).
2. The new field values coming from the DML request (whether it comes from the Save button on a page layout, from a Process Builder or workflow rule, or from Apex code or a SOAP/REST API call) overwrite old values:
   • If the record is updated/inserted from the user interface (for example, page layout), the Salesforce engine executes some system validations to check the record before submitting it:
     • Checking required fields defined at the layout level or the field level
     • Field format validation (for example, the email field)
     • Field length
   • If the record comes from Apex code or a REST/SOAP API call, Salesforce only validates foreign keys and checks whether they refer to the object itself (for example, it checks whether the Case.ParentCase field refers to the object itself. They are usually called circular references and are not allowed.).

3. Any Apex trigger is executed with the before event: without going into further detail, Apex triggers respond to events that occur around a record's database commit. The before event happens right before the record is saved into the database but not actually committed.
4. All validation rules are run, both system (required fields at the field level) and user-defined ones. In this step, layout-specific rules are not enforced again.
5. Duplication rules (refer to Chapter 7, Improving Data Quality with Duplicate Management) are evaluated, and if the block action is in place and a duplicate is found, the record is not saved at all and this flow breaks.
6. The record is saved to the database (but not yet committed).
7. Any Apex trigger is executed with the after event.
8. Any assignment rules are executed. We haven't talked about assignment rules. They are just used to assign cases and leads to the proper users/queues. Refer to Salesforce Help at https://help.salesforce.com/articleView?id=creating_assignment_rules.htm&type=5 for more details.

9. Any auto-response rules are executed. They are used to send quick email responses to customers when a lead or case is created. Refer to Salesforce Help at https://help.salesforce.com/articleView?id=creating_auto-response_rules.htm&type=5.
10. Workflow rules are executed: no order of execution on workflow rules is enforced, as we already said we cannot determine which workflow rule is run first.
11. If workflow rules execute field update actions, the record is updated a second time, leading to the following automation chain:
    • Before and after trigger code is executed one more time (and only one).
    • Standard validation rules (such as on required field) are reevaluated (custom validation rules and duplicate rules are excluded from this round).

This means that you can create records with invalid field values according to validation rules: take this into account when troubleshooting issues.

12. Process Builder is launched along with autolaunched flows: if a process or flow executes an update or insert, the affected record walks through this path one more time.
13. Escalation rules are executed. This is used for allowing a case to be escalated if certain conditions are met. Refer to Salesforce Help at https://help.salesforce.com/articleView?id=rules_escalation_create.htm&type=5.
14. Entitlement rules are executed (refer to Chapter 6, Service Cloud Applications).
15. If a parent record's roll-up fields need to be updated or is part of a cross-object workflow, the parent is then updated and walks through this same order of execution path.
16. If a grandparent record needs to be updated (because of a roll-up field or another cross-object workflow on the parent), it is updated and walks through this same save path.
17. Criteria-based sharing rules are evaluated (refer to Chapter 1, Secure Data Access).
18. The record is committed to the database (meaning that nothing can go wrong from now on, and the record is finally available to anyone in the organization with its new values).
19. Any post-commit logic event is executed, such as sending emails.

With a recursive save (that is, the same record that started this path is updated in one of these steps), step 8 to step 16 are skipped and only executed for the first iteration.