Salesforce orgs accumulate automation logic over years — Apex classes, triggers, Flows, Process Builders, and OmniStudio components 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 chain: what triggers this, what does it call, and what will break if I change it?
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
Connected and synced Salesforce Org
View or Edit permissions on the Org Model
Org AI Analysis feature enabled for your space (contact your Elements account manager or Elements support to enable this)
The selected automation component must have a generated Summary — the Execution context depends on individual summaries to build the chain narrative.
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:
Purpose: A plain-language explanation of why this automation exists in business terms — what problem it was built to solve and what business outcome it produces.
When it runs: All known invocation paths for the automation — direct and indirect. This includes triggers from buttons, page layouts, platform events, and other automations. Where invocation paths cannot be determined from static analysis alone, the explainer is transparent about the limits of its confidence.
What it touches and invokes: The fields and objects the automation reads or writes, and any downstream automations it calls. Understand the full blast radius before making a change.
Larger process: How the selected automation fits into the end-to-end chain — from root trigger to final outcome. The explainer summarises the logic of all automations in the chain, not just the one you clicked on.
Why it's risky: An assessment of the risk associated with changing or removing this automation — including complexity, coupling to other parts of the system, and execution frequency. Helps you prioritise what to investigate before making changes.
Confidence score: A score that tells you how certain the analysis is, and why. Where Salesforce metadata limits full visibility — for example, dynamic references or runtime-only invocation paths — the explainer flags this explicitly so you know where to verify manually.
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 summer 2026.
Limitations
The Execution context relies on static dependency analysis and AI-generated summaries. Be aware of the following:
Dynamic references in Apex. Dynamic SOQL/SOSL queries, runtime-determined method calls, and string-based references cannot be fully traced from static metadata. The chain narrative may not capture invocation paths that are only determined at runtime.
Platform events. Publisher and subscriber relationships are traced through dependency data. If a Flow publishes a platform event, the downstream subscribers should appear in the chain, but the connection depends on the dependency data being complete after sync.
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.