What really runs when a Salesforce record is saved.
Every org grows its own tangle: a before-save flow here, a trigger from a package there, three validation rules, a workflow field update that quietly fires the triggers a second time, a roll-up that saves the parent account and starts it all again. When a save is slow, fails with a validation error nobody wrote, or updates a field "by itself", the first question is always the same: what runs, and in what order?
savepath answers it from the org's own metadata and, when you have one, from a debug log.
sf plugins install @illinifellow/plugin-savepath
sf savepath explain --sobject Opportunity --operation update --target-org prod
sf savepath replay --log ./logs/07L5g00000ABcDe.log --slowest 10explain lists every active flow, trigger, validation rule, duplicate rule and workflow rule in the step where Salesforce runs it, and warns when record-triggered flows have no trigger order. replay turns a debug log into a timeline of units with duration, SOQL and DML per unit, and the limits used.
force-app/ is an unlocked package with a Lightning app page: pick an object and an operation and see the same timeline, with inactive automation greyed out. The Tooling API is called from Apex through a Named Credential; nothing leaves the org.
Salesforce documents it in Triggers and Order of Execution in the Apex Developer Guide. savepath follows that page step by step, including the parts people forget: workflow field updates re-running before and after triggers once more, and roll-up summaries sending the parent record through its own save.
- The order of execution is Salesforce's own documentation; savepath only makes it concrete for your org.
- Apex debug log line formats as documented in the Apex Developer Guide.
- Built on
@salesforce/sf-plugins-coreand oclif.
BSD-3-Clause, like the sf CLI plugins it sits beside.