4 Steps to Eliminate Identity Debt and Build Reliable Agentic AI with Data 360

Consider this scenario. You are reviewing the final data flows for your upcoming Agentforce rollout. You look at your records and realize that your data looks clean in isolation, but the relationships between the data points are fundamentally broken. 

You notice that a premium customer record in Agentforce Service shows zero previous purchases, even though that same individual just bought a high-value item in Agentforce Commerce. They are not seen as the same person, simply because they used a different email alias during checkout. The inability to reconcile records for the same person when different email aliases are used can be described as identity debt, but it can be addressed. 

Identity debt occurs when organizations accumulate disjointed customer profiles across multiple systems over time. Resolving this situation requires you to take a step back before you can move forward. You need to ensure that a unified identity is created so that the data provides the necessary context when an autonomous agent interprets it.

Resolving identity debt requires more than cleaning individual records. It requires creating a golden record, a trusted representation of each customer, and exposing it through what I call an architecture of truth: a system of context that every application and AI agent can rely on as the authoritative source of identity. 

Recognize the hidden costs of identity debt

It should come as no surprise that when you deploy artificial intelligence on top of fragmented identity data, you amplify existing data flaws. Large language models (LLMs) rely on precise context to generate accurate responses. If your underlying data model cannot definitively determine whether “John Doe” the lead is the same person as “J. Doe” the contact on an escalated support case, your AI agents will inevitably provide incorrect, incomplete, or conflicting information.

As you can see from this example and the email alias example above, this is not a theoretical problem. Poor identity resolution directly undermines the Reliable and Secure principles described in the Salesforce Well-Architected Framework. Unreliable data leads to unpredictable and incorrect agent behavior. On top of that, if an agent accesses data that belongs to the wrong profile because of an identity mismatch, you risk security and privacy breaches.

Construct the architecture of truth in four deliberate steps

To resolve identity debt, apply the following four-step framework that helps eliminate data fragmentation, establish a trusted system of context, and deploy a reliable system of agents.

Step 1: Standardize ingestion of identity data from legacy sources 

When systems send data at different speeds, out-of-order updates can silently overwrite current customer data with legacy records. If an operational platform streams a real-time address change, but a legacy ERP pushes a weekly batch overnight without timestamps, the older ERP record wins, reverting the customer’s profile back in time. Implementing sequencing controls and CDC watermarks before ingestion is essential. Without them, your AI agents will ground their reasoning in obsolete data and take incorrect actions on behalf of the customer.

Once you have ingestion timing and sequencing controls in place, implement data profiling to quantify your existing identity debt, then apply standardized transforms using MuleSoft or Data 360 connectors. Standardize phone numbers to E.164 format, enforce ISO country codes, and trim trailing whitespace from email addresses before they land in data lake objects (DLOs).

A trap to watch out for is debt incurred from unstructured data. Legacy systems frequently bury physical addresses, alternate phone numbers, or account notes inside free-text fields. Extract structured attributes from legacy notes prior to identity resolution to help ensure critical data points aren’t overlooked during matching.

Step 2: Resolve core identities and define survivorship

The real test for when native Data 360 matching stops being enough comes down to three questions: 

• Do you have consumers of the resolved identity record outside Salesforce? 
• Does identity stewardship require human-in-the-loop workflows? 
• Do matching rules need to be governed by an enterprise team outside Salesforce? 

If the answer to any of these is yes, you need an enterprise Master Data Management (MDM) platform like Informatica. If not, relying on the native identity resolution capabilities of Data 360 minimizes integration friction and gives Agentforce immediate operational context.

Once you establish where your identity resolution engine lives, execute a tiered matching strategy, progressing from deterministic exact matches using a trusted enterprise identifier (such as an MDM ID or another canonical identifier) to fuzzy and probabilistic matching.

The trap to avoid here is over-merging. Shared identifiers, such as spouses using a single household email address, will collapse distinct individuals into an unusable Frankenstein profile unless you enforce compound rules like “Name + Email”. Finally, establish field-level survivorship based on trust and recency. For instance, let the Billing system always win on physical addresses, while letting Marketing win on phone numbers if updated in the last 30 days.

Step 3: Harmonize unified profiles into a single model

If you skip this step of harmonization of unified profiles into a single model, your AI agent cannot traverse the data graph natively. It falls back to guessing relationships between raw, ungrounded database tables, which is a source of cross-domain hallucinations. Harmonization turns resolved identity data into a structured, readable system of context for LLMs.

To achieve this, take the cleansed DLOs created during Step 1 and map them into standard Customer 360 data model objects (DMOs) to establish a canonical schema. Mapping the objects is only half the task: you must also explicitly define the relationships between these DMOs, linking Order DMOs and Case DMOs directly to the Individual DMO. This relational schema produces a unified interaction timeline where an Agentforce for Commerce purchase, a Marketing Cloud email click, and an Agentforce for Service case become sequential events for one person rather than three unrelated records.

The part that’s easy to miss is engagement data. When you merge a duplicate lead and contact, their historical clicks, cases, and orders must be re-parented to the new identity record. Attribute-level identity resolution without re-parenting leaves you with a clean profile and a fractured history.

Step 4: Activate the resolved data for agentic AI

The real test for activating resolved identity data is whether your security architecture enforces dynamic user-context boundaries. Securing field-level permissions and sharing rules at the activation layer ensures that cross-domain visibility doesn’t compromise data governance. This is important because merging customer data into a unified golden record creates a severe privacy risk if an agent surfaces restricted fields to an unauthorized user.

Activating data for Agentic AI goes beyond pushing segment lists to downstream tools; it means surfacing this unified context directly into the agent’s reasoning engine. To anchor your agent in practice, configure Agentforce actions and prompt templates to query the harmonized data graph and Data 360 retrievers rather than issuing direct queries against raw CRM tables. This guarantees the LLM automatically traverses the DMO relationships built in Step 3 when retrieving customer context.

A critical part of this activation is reducing runtime computation for the LLM. Avoid asking the agent to aggregate historical orders or compute risk metrics on the fly. Instead, build calculated insights, such as Lifetime Value, Churn Risk, or aggregated channel sentiment, directly onto the unified DMOs. Surfacing these precomputed metrics inside the prompt window enables agents to instantly ground their decisions in accurate context without hallucinating.

Apply core data principles to your existing architecture

To maintain this architecture over time, you must enforce strict data governance principles. Treat identity resolution as an ongoing process rather than a one-time project.

• Start by enforcing single-source authority for critical data fields. Ensure that downstream systems subscribe to your newly established truth rather than creating their own localized profiles. 
• Next, implement continuous data quality monitoring. Measure your consolidation rate, the percentage reduction from raw source records to unified individual profiles, and configure Data 360 flow triggers to automatically alert data stewards whenever match rates drop below acceptable baseline thresholds.
• Finally, design for traceability. Your system of context must maintain an audit trail so that administrators can understand exactly why two records were merged or why a specific data point won out over another.

Prepare your systems for trustworthy agentic deployments

Building a reliable identity is a prerequisite for a trustworthy Agentforce deployment, not a nice-to-have. Start by auditing where identity resolution is currently happening in your stack. If the answer is “everywhere” or “in the application layer,” you have an architectural decision to make before your agents can be reliable.

Do not wait until your AI agents start hallucinating to fix your underlying data architecture. Schedule a whiteboarding session with your platform owners this week to map out your current identity flows, identify critical consolidation points, and design an architecture that resolves identity once, upstream, rather than forcing every downstream application or AI agent to reconstruct customer identity independently. 

What to do next:

• Watch the Salesforce+ TDX session: Design a Golden Record: The Architecture of Truth
• Review the Salesforce Architecture Center guide on Data 360 Security Architecture
• Complete the Trailhead module: Data and Identity in Data 360