Salesforce fields get their values from many places at once - Flows, Apex, Workflow field updates, quick actions, page layouts, and users typing into a record. When a value is wrong, the usual question is "where did this come from?", and answering it normally means opening each automation one by one.
The Data lineage sub-tab on the Context panel answers that question for a selected object or field. It analyses everything that can set the value, together with who has permission to change it, and produces a short plain-language report - without requiring you to read code or trace dependencies manually.
TIP: Data lineage explains what writes to an object or field. To see everywhere a component is referenced, use the Insights tab. To understand what a single automation does, use the Automation summary sub-tab.
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 a data lineage summary
Select an object or field in the metadata dictionary or from the Salesforce sidebar. Open the Context tab in the right sidebar panel, then select the Data lineage sub-tab and click Analyze sources of data.
The summary is generated on demand rather than stored, so the Context tab does not show counters. Generation typically completes in under 10 seconds for a commonly used field such as Case Status or Opportunity Stage, and a loading indicator is shown while it runs.
What the data lineage summary shows
The data lineage summary is written in business language and is deliberately concise. It has four sections:
How it's updated automatically - the Flows, Process Builders, Apex classes and rules that write to the object or field, with a one-line explanation of what each one does.
Where users can set it manually - the page layouts and Lightning pages where the field is editable or required, plus any global actions or quick actions that surface it.
Who can change it - the profiles and permission sets that grant edit access, and the total number of users who hold Edit or Create access.
Risks and data integrity conflicts - conflicts worth investigating, such as multiple Flows writing to the same field (a potential race condition), or a field that is required on some layouts but not others.
How data lineage is worked out
Elements builds the data lineage report from the dependency and permission data held in your Org Model, then uses an AI model to turn it into a business-language explanation. What Elements collects depends on what you selected.
For an object, Elements finds the metadata that writes records to it: Flows, Process Builders and Apex classes where write access is recorded, plus any global actions and quick actions on the object. Where one of those automations is itself invoked by another Apex class, Apex trigger or Flow, Elements follows the chain upwards until it reaches the root of the automation.
For a field that is not a formula field, Elements finds the metadata that sets its value: Flows and Process Builders that write to it, Workflow field updates, global actions and quick actions, and page layouts and Lightning pages where the field is editable. An Apex class is included only when that same class also writes to the field's parent object.
For a formula field, Elements reads the formula definition and follows the fields that the formula references. Where a referenced field is itself a formula field, Elements follows that formula too, and keeps going until it reaches fields that are not formulas - then reports what writes to those.
For permissions, Elements reads the access data for the component. For an object, it reports the profiles and permission sets granting Create, Edit or Modify All. For an optional field, it reports who has Edit access on the field. For a required field, it reports who has Create, Edit or Modify All on the parent object, because anyone who can create or edit the record has to supply a value.
Supported metadata types
The Data lineage sub-tab is available for the following metadata types only:
Custom object
Standard object
Managed object
Big object
External object
Custom field
Standard field (including formula fields)
For automation metadata such as Apex classes and Flows, use the Execution context sub-tab instead, which explains the automation chain rather than the sources of a value.
Limitations
Data lineage is built from static dependency analysis, so there are sources of data it cannot yet see:
Apex triggers, Visualforce and OmniStudio automations are not currently included as sources of data. If a value is set by one of these, it will not appear in the report. Support for those is expected by end of 2026.
The report reflects your last completed Salesforce sync, not live changes in your Org. Metadata added or changed since the last sync is not included.
Dynamic references in Apex - dynamically constructed field references and runtime-determined method calls cannot be traced from static metadata, so writes made this way may be missing from the report.
Tips
Use Data lineage when investigating a data quality issue - it tells you every automation and every screen that could have set the wrong value, in one place.
Run Data lineage before deprecating a field, to see which automations still write to it and how many users can still edit it.
Combine Data lineage with the Why it exists sub-tab for the full picture: where the data comes from, and why the field was built in the first place.