Showing Data 360 data on a Salesforce record page: related lists, copy fields, and the mapping that makes it work

You spent a quarter standing up Data 360. Streams are ingesting, identity resolution is merging the fragments, and a unified individual now carries a customer’s web behavior, order history, loyalty tier, and consent in one governed profile. Then a service rep opens that customer’s Contact record to take a call — and sees exactly what they saw before the project started. Name, a couple of phone numbers, some cases. None of the unified profile. Because the rep lives on the Lightning record page, and everything you built lives one product over, in a place they will never open.

This is the quiet failure mode of a lot of Data Cloud programs. The unification is real, the grounding for an agent is real — and the human on the phone gets none of it, because nobody wired the last hundred feet. Surfacing unified data back onto the CRM record is a specific, under-documented job, and it has two native mechanisms with a sharp difference between them, one prerequisite that silently breaks both, and a case where the right answer is “don’t do this at all — build a data graph instead.”

Two doors: copy fields store, related lists show

Salesforce gives you two supported ways to bring Data 360 data onto a core CRM record — Contact, Lead, or Account. They look similar in the setup menu and do fundamentally different things, and picking the wrong one is the difference between a field that’s always stale and a related list that’s always empty.

Copy Field Enrichment copies a value out of Data 360 and writes it onto a field on the CRM record. It’s a 1:1 map: one field on a data model object (DMO) to one field on a Contact or Lead. If you calculate lifetime value in Data 360 and a unified individual comes out at 1,500, a copy field writes 1500 onto a currency field on that person’s Contact. The value now physically lives in CRM. It’s queryable in SOQL, usable in a Flow entry condition, filterable in a list view, referencable in a validation rule — because as far as the platform is concerned, it’s just a field on Contact.

Related List Enrichment does the opposite: it shows Data 360 records on the CRM record home without copying anything into CRM. It builds a lookup relationship from a DMO to the CRM object, then renders a related list of matching Data 360 records — every email engagement, every order, every web session tied to that person — read live from Data 360. Nothing is stored in CRM. Navigate away and there’s no copy left behind; the data stays where it was ingested and governed.

The one-line rule: a copy field is for a scalar you want to act on in CRM logic — a score, a tier, an LTV — so it has to physically land on the record. A related list is for a set of records you want a human to read — engagements, transactions, interactions — so it should stay in Data 360 and be shown, not duplicated. Reach for copy fields when Flow or a report needs the value; reach for related lists when a person needs the history.

That storage difference drives everything downstream: cost, freshness, and what the data can and can’t do once it arrives.

Copy fields: the value lands on the record, on a schedule

A copy field enrichment maps a field on a source object to a field on a target, and the target is deliberately narrow. As of the enrichment feature’s requirements, the source must be a DMO (or a one-dimensional calculated insight object) that holds a 1:1 relationship to the Individual or Unified Individual DMO — one value per person — and the target must be a Contact or Lead field of a compatible type. That 1:1 constraint is the whole point: a copy field carries a single scalar per person, not a collection. Lifetime value, a churn or engagement score, a computed segment membership, a loyalty tier — one number or one string that describes the whole individual.

Setup lives in the Data Cloud admin surface: create the enrichment, choose the source DMO and field, choose the target object and the field to write to, and define the matching that ties a unified individual back to the specific CRM record. Then the platform populates it.

The trade-off to say out loud to your team is freshness. A copy field is a copy. It reflects the value as of the last enrichment run, not the value right now. For LTV or a churn score that shifts on a daily cadence, that’s completely fine — nobody needs churn risk recalculated to the second on a Contact. For anything that has to be exactly current at read time, a stored copy is the wrong shape, and you want a related list (live) or, for an agent, a data graph (low-latency live). The failure you’re avoiding: a rep making a retention decision off a copy field that reflects last week, because nobody told them the number is a snapshot.

One more discipline. Because copy fields write real data into CRM, they inherit CRM’s storage and its governance. A score copied onto Contact is now visible to anyone with read on that field, subject to your field-level security, and counted in your data storage. Copy the handful of values your CRM processes genuinely need to branch on — not the whole profile because you can. If you find yourself wanting to copy fifteen fields, you probably want a related list or a graph, not fifteen copies.

Related lists: show the history without moving it

Related list enrichment is the one most teams actually want and don’t know exists. It answers the request every service manager makes the first time they see a unified profile: “can I just see all of this on the Contact?”

Mechanically, it creates a lookup relationship from a DMO to a CRM object, and then you drop a related list onto the record home that renders the matching DMO records. The supported shapes, per the feature’s requirements, are the ones that make sense as a list: Unified Contact Point objects (every phone, email, and address resolved to the person) and engagement DMOs that have an effective many-to-one relationship to the unified individual or account — email engagements, web engagements, orders, whatever behavioral streams you’ve ingested. The supported CRM targets are Contact, Lead, and Account. So “show every email engagement we’ve ever sent this person, from every source system, on their Contact record” is exactly the intended use — and none of it is copied into CRM.

The setup is closer to classic Salesforce than the Data Cloud parts of it suggest:

Setup → Object Manager → Contact → Data Cloud Related Lists → New
  1. Data Cloud Object:  Unified Individual Email Engagement (the DMO to show)
  2. Child Relationship Name:  Data_Cloud_Email_Engagements
  3. Related List Label:  Email Engagement (Data 360)
  → Save

Then: Setup → Lightning App Builder → Contact Record Page
  → add/enable the Data 360 related list on the page
  → choose columns and sort order, just like a native related list

Two things surprise people here. First, creating the related list does not put it on the page — you still have to edit the Lightning record page and add it, exactly like a native related list, which is why admins swear the feature is broken when it’s just not on the layout yet. Second, the columns and ordering are yours to configure; this is a real Lightning related list, not an opaque embedded widget, so you tune which fields show and how they sort the same way you always have. Salesforce also ships purpose-built Lightning components in the same family — a Data Cloud–related records component and profile/engagement widgets that surface unified engagement directly on Contact, Lead, and Prospect pages — but the Object Manager related list is the workhorse and the one to learn first.

The prerequisite that silently breaks both

Here’s the step that isn’t in the “add a related list” instructions and quietly defeats every team that skips it: the CRM record has to be resolved to a unified individual, and the mapping has to actually match.

Both mechanisms depend on a chain: the CRM Contact maps to an Individual in Data 360 (through your Salesforce CRM data stream and mapping), identity resolution collapses that Individual and its duplicates into a Unified Individual, and the enrichment matches back from the unified individual to the right Contact. Break any link in that chain and the symptom is identical — an empty related list or a blank copy field on a record you know has data in Data 360. The data is there; the join to this CRM record isn’t.

So the real precondition for surfacing anything is that your identity resolution and your CRM-to-DMO mapping are correct first. If the Contact was never ingested and mapped to an Individual, there’s nothing to match. If your match rules over-merged two people into one unified individual, the related list shows another customer’s engagements on this Contact — which is worse than showing nothing, because now it’s a privacy incident on a record a rep trusts. Get the unification right, verify a known record end to end, then wire the display. The display layer is easy; it just faithfully reflects whatever the unification did, including its mistakes.

When a related list is the wrong tool

The most useful thing to know about these features is where they stop. Copy fields and related lists exist to put unified data in front of a human looking at a record page. They are not how you ground an agent.

An Agentforce agent reasoning over a customer doesn’t read a Lightning related list. It needs the unified profile as low-latency, structured data it can retrieve inside a conversational turn — and reconstructing “everything about this person” by joining fifteen DMOs on demand is exactly the operation that blows a latency budget. That’s what a data graph is for: a pre-joined, denormalized materialization the agent queries in milliseconds. If your goal is an agent that knows the customer, build a data graph and skip the record-page plumbing entirely. If your goal is a rep who can see the customer, build the related list and skip the graph. Teams burn weeks because they conflate the two — trying to feed an agent through a related list, or standing up a graph to populate a Contact page. They’re different surfaces for different consumers.

The same split governs governance. A related list on a record page inherits the viewing user’s permissions and your Data 360 sharing, so a rep sees what they’re entitled to see — the human-facing half of the story we tell in full in making sure your agent only sees what the user can see. Decide who should see a unified profile before you put it on a page that your whole service org opens fifty times a day.

The pattern that works

Put together, the record-page layer of a Data 360 program comes down to three moves in order:

• Unify first, display last. Get identity resolution and CRM mapping correct and verified on a known record before you add a single field or list. The display faithfully reflects the unification — including any over-merge — so the profile is only as trustworthy as the match rules underneath it.
• Copy the scalars you’ll act on; show the records you’ll read. A short, deliberate set of copy fields for the values your Flows, reports, and list views branch on. Related lists for the engagement and contact-point history a human needs to see. Resist copying the whole profile into CRM because the button lets you.
• Match the surface to the consumer. Record page for humans, data graph for agents. If you catch yourself building one to serve the other, stop — you’ve picked the wrong tool, and it will be slow, stale, or both.

Done right, the last hundred feet is the cheapest, highest-visibility part of the whole program: the rep opens the Contact they always open, and the unified profile you spent a quarter building is finally there. If you’re weighing whether a Data 360 investment is even warranted for your use case before you get this far, the honest dependency map in does Agentforce need Data Cloud is the place to start — and our financial services work is mostly this exact pattern: unify the fragments, then put the one governed profile in front of the person who’s about to make a decision on it.