When a record is created or updated in Salesforce, a long sequence of validation, automation and recalculation fires in a fixed order. Salesforce documents that sequence in general, but it does not tell you which parts apply to your object - so working out what will actually run on your Account or Case means opening every validation rule, flow, trigger and workflow rule one by one.
The Order of execution sub-tab on the Context panel does that for you. Select an object, and Elements lists every active automation on it in the order Salesforce will run it, explains what each one does in business language, and flags where automations may be tripping over each other.
TIP: The Order of execution summary is an object-level view: it answers "what happens when a record is saved on this object?". To understand a single automation and the chain it sits in, use the Execution context sub-tab instead.
Prerequisites
Registered and verified Elements account
View or Edit permissions on the Org Model
Org AI Analysis add-on enabled for your space (contact your Elements account manager or Elements support to enable this)
How to generate an order of execution summary
Select a custom object or standard object in the metadata dictionary or from the Salesforce sidebar. Open the Context tab in the right sidebar panel, then select the Order of execution sub-tab.
The summary is generated when you click 'Analyze order of execution' action button. Because Elements has to gather every automation attached to the object, generation on a heavily automated object such as Account or Case can take a little longer than the other Context sub-tabs.
What the order of execution summary shows
The order of execution summary is written in business language and has four parts.
Automations that run before the record is saved, listed in the order Salesforce runs them:
System and user interface validation - fields that are required on the object, and fields made required on a specific page layout or Lightning page
Validation rules
Before-save record-triggered flows
Before-save Apex triggers
Duplicate rules
Automations that run after the record is saved, again in execution order:
After-save Apex triggers
Assignment rules
Auto-response rules
Workflow rules
Escalation rules
Processes and flows - Process Builders, any flows those Process Builders launch, and after-save record-triggered flows
Entitlement processes
Roll-up summaries, both on the parent object and on the grandparent object
Sharing rules
Asynchronous processing - flows and Apex that run after the transaction completes
Each component is listed with its type and name, followed by one or two sentences explaining what it does and under what criteria. Where a category has no active components on the object, it is marked as not found rather than left out, so you can see what Elements checked.
Risks and complexity observations - a short, evidence-based assessment: where logic is concentrated, where automation types overlap, whether legacy automation such as Workflow Rules or Process Builder is still in play, how many blocking rules stand between a user and a successful save, and what side effects land on related records.
Data migration and bulk load considerations - practical guidance if you are planning to load data into the object: which fields are required, which validation and duplicate rules will reject records, how much before-save and after-save automation each record will trigger, what cascades out to related records, and whether phased loads or controlled batches are advisable.
How the sequence is worked out
Elements assembles the order of execution summary from your Org Model rather than from a live trace of a transaction. It collects the automation attached to the selected object - required fields, fields made required on a page layout or Lightning page, validation rules, before-save and after-save record-triggered flows, before-save and after-save Apex triggers, duplicate rules, assignment rules, auto-response rules, workflow rules, escalation rules, Process Builders and the flows they launch, entitlement processes, sharing rules, asynchronous flows, and roll-up summary fields on the parent and grandparent objects.
For flows and triggers, Elements also reads how each one is configured: its trigger type, whether it runs immediately or asynchronously, and its trigger order. Those attributes determine where a component sits in the sequence.
Elements then combines this inventory with the automation summaries already generated for each component, and uses an AI model to place everything into Salesforce's documented order of execution and describe it in business terms.
Only active components are included. Inactive validation rules, workflow rules, duplicate rules, escalation rules, assignment rules, auto-response rules, entitlement processes and Process Builders are left out, because they will not run.
Supported metadata types
The Order of execution sub-tab is available for two metadata types:
Custom object
Standard object
The Order of execution sub-tab is not available for fields, automation components, or other metadata types. To see what sets the value of a field, use the Data lineage sub-tab.
Limitations
The order of execution summary is built from the metadata in your Org Model, so keep the following in mind:
The summary reflects your last completed Salesforce sync, not live changes in your Org. Automation added or activated since the last sync is not included.
It covers the automation types listed above, not every step in Salesforce's order of execution. Steps such as post-commit logic, email delivery and platform event publishing are not itemised. Treat the summary as a map of your own automation, and use Salesforce's order of execution documentation as the authority on the platform sequence itself.
Managed package components are described only by name. Elements cannot read the definition of managed package metadata, so those components appear in the sequence without a business explanation.
Apex called indirectly is not listed separately. Apex triggers on the object are included, but the classes those triggers call onward are not itemised in the sequence. Use the Execution context sub-tab on the trigger to follow the chain.
Tips
Run the order of execution summary before a data migration or bulk load. The data migration section tells you which rules will reject records and how much automation each row will fire, which is usually what determines batch size.
Use it when rationalising legacy automation - the summary makes it obvious where Workflow Rules, Process Builder and Flow are all still running on the same object.
Use it to onboard new admins to a complex object. Instead of opening twenty components in Setup, they can read one sequence and understand what happens on save.
Combine it with the Why it exists sub-tab on individual components when the summary surfaces something that looks redundant.