Declarative Automation
The toolkit and the order
Know what each tool does and when it fires. Before-save record-triggered flows (like before triggers) change fields on the same record with no extra DML. Validation rules then block bad saves. After-save record-triggered flows, workflow rules, processes, assignment rules, auto-response rules, and escalation rules run later and can create or update other records. Workflow rules and Process Builder are legacy - new work belongs in Flow - but you must reason about them during migrations.
Simplified order of execution: load the record → before-save automation → validation rules → duplicate rules → save to the database → after-save automation, workflow, and assignment → roll-up recalculation → post-commit actions such as emails and async queues.
Traps
- Workflow field updates do not re-fire validation rules; a rule can be bypassed this way. Before-save flow field changes behave the same.
- After-save flows that update their own triggering record need entry conditions and fault paths to avoid runaway recursion.
- Scheduled actions fire when their condition is met, not when the flow was saved.
- Bulk operations run in batches; per-transaction governor limits and daily interview limits can fail a large load that works fine in the UI.
- Fault paths are required for anything that changes other records - an unhandled fault fails the whole transaction.
Worked example
Set Discount to 10% when Stage = Closed Won. That is a same-record field update: use a before-save flow with an Assignment element, no Update Records element. Sending an email and creating a task belong in an after-save flow or a scheduled path.