Salesforce orgs accumulate automation logic over years - Apex classes, triggers, Flows, Process Builders, Omniscripts, and others, that call each other, fire in sequence, and depend on shared objects and fields. Understanding what a single automation does is useful, but in practice, most questions are about the entire logic chain:
how all the automations relate together?
what process is executed end-to-end?
what will break in this process if I change this one apex class?
The Execution context sub-tab on the context panel answers these questions. It analyses the full automation chain for a selected component and generates a plain-language narrative that explains the end-to-end execution flow in business terms - without requiring you to read code, trace dependencies manually, or rely on a specialist engineer.
Prerequisites
Registered and verified Elements account
View or Edit permissions on the Org Model
The Automation & Execution Intelligence add-on enabled for your Space (contact your Elements account manager or Elements support to enable this)
What the Execution context shows
The Execution context produces a narrative that explains the full automation chain for the selected component.
The execution context tab covers:
The execution chain : an ordered list walking source of the automation chain to its destination target.
Each step names the component, its type, and one line on what it contributes. The selected component is marked in place. Where the entry point can't be determined, it is flagged.
What the chain achieves the business outcome of the whole chain, not just the selected component component. If the chain has one link, say that the component runs standalone.
This component's role in the chain: what this selected metadata contributes to the outcome above. Not what it does internally.
Change impact what kinds of change to this component propagate, and to what. Grounded in the chain: scope changes, contract changes between steps, ordering and volume effects.
Confidence score - unchanged.
How chain analysis works
The Execution context does not analyse the selected automation in isolation. It works in three steps:
Graph construction. Elements reads the dependency data for the selected component and builds a graph of all related automations: what calls it, what it calls, and any further downstream dependencies.
Summary collection. The individual automation summaries for each component in the graph are gathered.
Narrative generation. An AI model reads the graph structure together with the individual summaries and produces a single plain-language explanation of the full chain, with the selected component highlighted in context.
Because the chain analysis depends on individual summaries, any component in the chain that does not have a summary (for example, a managed package component) will be noted but may not be fully explained in the narrative.
Supported automation types
The Execution context is available for automation metadata types. This includes:
Apex Class
Apex Trigger
Flow
Process Builder Workflow
All other automation metadata types are planned to be supported by the end of 2026.
Limitations
The Execution context relies on static dependency analysis and AI-generated summaries. Be aware of the following:
Cross-org dependencies. The Execution context analyses automation within a single synced Org. Integrations or callouts to external systems are noted in individual summaries but are not traced beyond the Org boundary.
Tips
Check the Execution context before making changes to an automation. The chain narrative tells you what upstream processes trigger it and what downstream processes depend on it - helping you assess the blast radius of a proposed change.
Use the Execution context to onboard new team members to a complex org. Instead of reading code or asking a senior engineer, they can open any automation and immediately understand how it fits into the overall system.
Combine the Execution context with the Insights tab - the Execution context explains what the automation chain does, while Insights shows you where each component is referenced across your Org.
When investigating an incident where a field has an unexpected value after a record save, open the relevant triggers or flows on the parent object and use the Execution context to trace the full chain of events that may have written to that field.