Cross-reference keys and lineage for traceability
How to keep a golden record traceable and its rules consistent: External ID fields and a child cross-reference object for source keys, lineage from each value to its source record, audit history of steward decisions, legacy audit fields set at load, and shared reference data through global value sets, stable picklist API names and classification metadata.
Given a customer scenario, recommend appropriate approaches and techniques to capture and maintain customer reference and metadata to preserve traceability and establish a common context for business rules.
~6 min read · 7 practice questions ·
What the exam expects
- Store every source system key on the master: one External ID field per source, or a child cross-reference object when one master carries many keys.
- Keep lineage from each golden value to its source record and an audit history of merge decisions.
- Preserve legacy creation dates and users when loading, so audit and service rules still work.
- Give business rules a common context with shared reference data: global value sets, stable picklist API names and classification metadata.
Key terms: External ID (a field holding a record identifier from an outside system); cross-reference object (a child object with one row per source key of a master record); lineage (the trail from a value back to its source record); global value set (one restricted list of picklist values shared across fields); audit fields (Created By, Created Date and similar system fields).
Key facts
- Detail
- Up to 25 per object (auto-number, email, number, text)
- Detail
- Update or upsert records through the API
- Detail
- Duplicates deleted; related records reparented
- Detail
- Carries Data Source ID and Data Source Object
- Detail
- Retains no source data; can't trace lineage alone
- Detail
- Full audit history for every decision
- Detail
- Set on create with Set Audit Fields upon Record Creation
- Detail
- The only audit field you can't set
- Detail
- Restricted; no unapproved values even through the API
- Detail
- Built on value API names
Sources for this section (7)
- Field Attributeshelp.salesforce.com (opens in a new tab)
- Merging Recordsdeveloper.salesforce.com (opens in a new tab)
- Unified Profilestrailhead.salesforce.com (opens in a new tab)
- MDM Capabilitiestrailhead.salesforce.com (opens in a new tab)
- System Fieldsdeveloper.salesforce.com (opens in a new tab)
- Global Value Setshelp.salesforce.com (opens in a new tab)
- Dependent Picklistshelp.salesforce.com (opens in a new tab)
- Why does a merge break key-based upserts when keys live only in an External ID field on the master?
- When must legacy Created Date values be set?
- Why can't an audit report on Unified Individual alone show where a value came from?
- What stops users and integrations adding a new value to a global value set?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Data Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 21 lessons of the Platform Data Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (7 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams