Let's take a detailed look at what is often referred to as the Order of Execution. This infographic outlines the key pieces of information Salesforce Administrators and Developers should understand.
This included things like your page layout required fields and several system integrity things. Are date values valid? Do emails follow the correct format? Are any of the fields too long? It's those types of things that occur in this step.
Record-Triggered Flow (Before)
This Flow is awesome as many of the things we'd have to rely on Apex Triggers for, the Admin can now do. If you have processes that need to update other fields within the same record that's being saved, this is where you'll likely want to place those.
Apex Before Trigger
This is a similar use-case to the Record Trigger Flow (Before). If you're wanting to update fields on the same record that is being saved, Apex Before Triggers have been the go-to standard for a number of years. I would expect Apex Before Triggers would be slightly more efficient than the Record Triggered Flow (Before) simply because they'd have less overhead than a Flow. I haven't validated that statement but it logically makes sense to me. :)
System & User Validation
The System Validation, mentioned in step one, runs again. Also, any Validation Rules defined on the object will run.
If you have Duplicate Rules enabled, they will run their check here. If a duplicate is identified, the user will be prompted to confirm the creation of the record.
What do you mean, the record is saved? If it's saved, aren't we done? This can be a little confusing at first. There are two parts to the save process. Yes, the record is saved and if it's a new record, it's assigned an ID. But, this is just another step in the process.
Apex After Triggers
Just like the Before Apex Triggers, this is code written by a developer. Generally speaking, the After Trigger is used when you need to update a record or object other than the one currently being saved. That is not 100% of the time rule, but it almost is. :)
Assignment Rules exist on the Lead and Case objects. If they've been defined, they would set the record owner during this step.
Hopefully, you're starting to transition away from the good "old" Workflow Rules. This was our only declarative automation tool for a number of years. Flows and Process Builder give us significantly more capability and I would encourage transitioning to before and after Record-Triggered Flows. The only exception is if you need to do an Outbound Message.
Process Builder / Flows
Process Builder runs first then any Auto-Launched Flows. When Process Builder was introduced, we loved it. We could control the order the processes ran and it had many great features. However, we quickly learned debugging these is a nightmare. With the introduction of Record Triggered Flows, I would recommend transitioning away from Process Builder. Record Triggered Flows do have some limitations but Salesforce is quickly pushing out enhancements, minimizing the reasons to resist the change.
Escalation / Entitlement Rules
Escalations and Entitlements are features of the Case object. Escalation Rules will run then Entitlement Rules will follow.
Record Triggered Flows (After)
After Record Triggered Flows have some capabilities not available in the Before Record Triggered Flows. This is because in the "after" save, we could be updating records other than the one being saved. I did find it interesting that this was placed nearly at the end of the process and not directly in front of the Apex After Trigger but I like it here as nearly everything is done.
Rollup Summary Calculations
If you have any Rollup Summary Fields on the parent record of the one being saved, those will calculate and update. This will cause the parent record to run through the full Order of Execution as well. Just keep that in mind.
The full process of saving the record is often referred to as a "transaction". The transaction is filled completed now. No errors occurred so the saving of your record is now completed.