Automation
Order of execution
Most automation questions are really order-of-execution questions. For a record save: system validation, then the before-save record-triggered flow, then custom validation rules, then duplicate rules, then save to the database, then the after-save record-triggered flow, then assignment rules, auto-response rules, workflow rules, processes, and escalation rules. Two consequences matter: a before-save flow can update the triggering record without a DML statement (a fast field update), and validation rules run after the before-save flow, so a flow that sets a field can still be blocked.
Choosing the tool
Workflow rules and Process Builder are legacy; new builds should use Flow. Record-triggered flows handle save-time logic, screen flows collect input, autolaunched flows run from buttons, Apex, or other flows, and schedule-triggered flows run at a set time for a batch of records. Time-based workflow actions still exist on legacy workflows and are evaluated by a background job.
Traps
- After-save flows cannot modify the triggering record without an update element, and are far more prone to recursion.
- Multiple record-triggered flows on the same object fire in an order you should verify, not assume.
- A flow element that fails without a fault path simply ends the interview, with no visible error to the user.
- Approval processes lock records, and locked records block edits from automation running in user context.
- Governor limits apply: bulkify, and never put SOQL or DML inside a loop.
Worked example
An after-save flow updates the same record that triggered it, re-fires, and eventually hits a limit. Fix it by moving the field update into a before-save flow (no extra DML, no recursion) or by adding an entry condition that excludes records already in the target state.
Rule of thumb: before-save for same-record field updates, after-save for anything touching other records.