Getting Data 360 fields onto the record: enrichments vs triggered flows

You did the hard part. You ingested the streams, resolved the identities, and Data 360 now holds a clean unified profile: a churn score, a lifetime-value band, a last-engagement date, computed across sources that used to disagree.

Then a colleague asks the obvious question. “Can we put the churn score on the Contact so the validation rule and the retention report can use it?” And you realize the value is sitting in a data model object, where a standard Flow, a validation rule, a rollup, and a report builder can’t reach it.

That gap surprises teams the most, because it’s invisible until you try to use the data. Unified attributes live in DMOs in the Data 360 space, and core CRM automation runs against sObjects. The two don’t share a field namespace, and closing that distance is a design decision with four defensible answers.

The rule that decides among them is short: copy a value onto the record only when a native field is the thing that has to exist, and query it in place the rest of the time. Copying costs storage, staleness, and a moving part. The default should be to leave data where it lives and reach for it. Below are the four bridges and when each one earns its cost.

First, why the field isn’t already there

Data 360 keeps unified data in its own objects, the data model objects, which is what lets it scale to volumes your CRM storage never could. If the distinction between the data lake and those model objects is fuzzy, the DLO-versus-DMO breakdown is worth ten minutes first, because every option here depends on it.

The consequence is the whole problem. A DMO field is not a field on the Contact. A validation rule references Contact fields, a record-triggered Flow fires on Contact DML, and a report type is built on sObjects. None of them can natively see a UnifiedIndividual__dlm attribute.

So to use unified data in CRM automation, you either bring the value across to the record or query the Data 360 objects directly. That is the entire menu, and it has exactly four items.

Bridge one: Copy Field Enrichment, for a value you need natively

A Copy Field Enrichment copies a value from a Data 360 DMO onto a mapped CRM record, so it becomes a real field you can use like any other. Copy Field Enrichment is the cleanest answer when the thing you need is a native field: something a validation rule checks, a report groups by, a list view filters on, or a page layout shows.

The constraint to know before you plan around it: direct association of Data 360 data is currently limited to Contacts, Leads, and Person Accounts. If the record you want to enrich is a custom object or a business Account, Copy Field Enrichment isn’t the tool, and you fall through to a triggered flow.

Setup lives in the Data 360 configuration, not in Flow. You choose a data space, a source DMO, the field to copy, and the CRM object and field it lands on.

The prerequisite that trips people up is identity. The DMO record has to be resolvable to the CRM record, so your identity resolution must already match the unified individual to that Contact or Lead. No match, no enrichment. Get the matching right before you wire the field.

Use Copy Field Enrichment when:

• The value changes slowly. A lifetime-value band or a segment tier is a good fit; a real-time counter is not.
• You need it in a declarative tool that only reads sObject fields, like a validation rule or a rollup.
• The target is a Contact, Lead, or Person Account.

Bridge two: Related List Enrichment, for showing the history

Sometimes you don’t need one value, you need the record’s related activity: every order, every case from another system, every web session tied to this person. A Related List Enrichment surfaces related Data 360 records as a related list on the CRM record page, without copying each one into a Salesforce object.

A Related List Enrichment is display, not data you can automate on. A rep looking at the Contact sees the unified order history inline, which is the point of the unified profile on the record page.

A Flow still can’t loop over that related list the way it can over child sObjects, so treat it as a UI feature for humans, not an input to logic. The same object constraint applies: Contacts, Leads, and Person Accounts.

Bridge three: Data Cloud-Triggered Flow, for logic when the data changes

When the value needs to do something the moment it changes, you want a Data Cloud-Triggered Flow. It fires when a DMO or a calculated insight meets a condition you set, and from there it behaves like a record-triggered Flow: it can create, update, or delete sObject records, call an Apex action, or send the change onward.

The triggered flow is the programmable bridge, right when a copied field isn’t enough. A churn score crossing a threshold that should open a retention Case, spin up a task, and update a custom field on a business Account all at once is a triggered-flow job, not an enrichment. We covered the build in depth in Data 360-triggered flows. Two things bite in production.

First, timing. The Flow runs after the DMO changes are committed, and how quickly that happens depends on your data stream refresh schedule, the volume of changes, and the complexity of the Flow. It’s near-real-time on a good day, not synchronous. Don’t design a user-facing interaction that blocks on it.

Second, the update trap. When a triggered flow fires on a DMO record update, practitioners repeatedly hit cases where prior values read as null, which breaks the “changed from X to Y” comparisons you’d rely on in a Sales Cloud after-save flow. Test your entry conditions against real update events, not the create path alone, before you trust them.

Triggered flows often lean on calculated insights, and those carry documented ceilings you should design within. Salesforce’s Data 360 limits cap the number of calculated insights per tenant, and cap manual runs and runtime per insight. Confirm the figures for your edition against the current limits reference before you assume headroom, because they change and they’re easy to hit at scale.

Bridge four: query it in place, and copy nothing

The option teams skip because it feels like more work is often the cheapest: don’t move the data at all. Query the Data 360 objects directly, at the moment you need the value.

From Apex you can run SOQL against DMOs, which end in the __dlm suffix:

List<UnifiedIndividual__dlm> profiles = [
    SELECT ssot__Id__c, ChurnScore__c, LifetimeValueBand__c
    FROM UnifiedIndividual__dlm
    WHERE ssot__Id__c = :unifiedId
    LIMIT 1
];

The mechanics, and the governor and connection limits that come with them, are in querying Data 360 from Apex and the SOQL-on-Data-360 walkthrough. The reason to prefer this is that it never goes stale, because there’s nothing cached to age, and it costs no extra storage.

Querying in place is the right call when:

• The value is read occasionally, not filtered or reported on across the whole object.
• Freshness matters more than the convenience of a native field.
• You’re grounding an agent. An Agentforce agent that needs a unified attribute should usually retrieve it at runtime rather than depend on a copied field that a delayed enrichment may not have refreshed yet.

The decision, in one pass

Run your requirement through these questions in order and you land on the right bridge without agonizing:

1. Does a declarative tool that only reads sObject fields need it, like a validation rule, a rollup, or a report filter? You need a native field. Use a Copy Field Enrichment if the target is a Contact, Lead, or Person Account.
2. Do humans just need to see the related history on the page? Use a Related List Enrichment.
3. Does a change need to trigger multi-step logic, or land on an object enrichments don’t support? Use a Data Cloud-Triggered Flow.
4. Is it read occasionally, or feeding an agent, where freshness beats convenience? Query it in place and copy nothing.

The trap underneath all four is the reflex to copy everything onto the record “so it’s easy to use.” Every copied field is storage you pay for and a value that can drift from its source between refreshes. The unified profile is the system of reference; the record is a convenience cache.

Copy the handful of attributes your declarative automation requires, show the rest, and query the long tail. An architecture that copies sparingly ages far better than one that mirrors the whole profile onto the Contact and then spends a year debugging why the two disagree.

Understanding the basics

Why can’t a Flow or validation rule see my Data 360 fields?

Data 360 keeps unified data in data model objects (DMOs), which are separate from the Salesforce sObjects that CRM automation runs on. A validation rule, a record-triggered Flow, a rollup, and a report type all reference fields on standard or custom objects, with no native visibility into a DMO attribute. To use unified data in that automation you either copy the value onto the record, or query the Data 360 objects directly at runtime.

What is a Copy Field Enrichment in Data 360?

A Copy Field Enrichment copies a field value from a Data 360 DMO onto a mapped CRM record so it becomes a real, native field you can use in validation rules, reports, list views, and page layouts. It currently supports Contacts, Leads, and Person Accounts, and it requires that identity resolution has already matched the unified profile to the target record. It’s the right choice for slowly-changing attributes that a declarative tool needs to read as an ordinary field.

Copy Field Enrichment or Data Cloud-Triggered Flow?

Use a Copy Field Enrichment when you only need the value to exist as a native field on a Contact, Lead, or Person Account. Use a Data Cloud-Triggered Flow when a change in the data has to drive logic, create or update multiple records, call Apex, or land on an object that enrichments don’t support. The enrichment is configuration that maintains one field; the triggered flow is a programmable process that runs after the DMO commit, subject to your stream refresh timing.

How do I query Data 360 data from Apex?

You run SOQL against the data model objects, which use the __dlm suffix, for example SELECT ChurnScore__c FROM UnifiedIndividual__dlm WHERE ssot__Id__c = :id. This reads the value in place with no copying and no staleness, at the cost of a query at runtime and the connection and governor limits that apply to Data 360 access. It’s the preferred pattern when a value is read occasionally or used to ground an agent, where freshness matters more than having a native field.

---

Deciding what to copy onto the record and what to leave in Data 360 is an architecture call with a real cost on both sides. Talk to us if you want that mapping designed once and correctly, or see how our Data Cloud practice gets the foundation right so unified data is usable rather than merely unified.