Get in Touch

Category: Data 360

  • Identity resolution in Data Cloud: the unglamorous work every agent depends on

    Nobody gets excited about identity resolution. It doesn’t demo well. There’s no slide where you show a reconciliation rule and the room leans in. But every time I’ve seen an Agentforce rollout wobble after go-live, the root cause traces back to the same place: the agent didn’t actually know who it was talking to.

    Data Cloud’s whole pitch is a unified view of the customer. Identity resolution is the machinery that builds that view. If it’s loose, every downstream capability, segmentation, personalisation, and now agent reasoning, inherits the mess.

    What identity resolution is actually doing

    Strip away the marketing language and it’s three steps. First, match rules decide which records across your Data Model Objects probably belong to the same person, using identifiers like email, phone, or a loyalty ID. Second, reconciliation rules decide which source wins when two matched records disagree on a field value, most recent, most trusted source, or a custom rule you define. Third, the result gets written to a unified individual profile that every other Data Cloud capability reads from.

    That sounds clean in a diagram. In a real org it’s messier, because the inputs are messier. A contact-centre case system might use a work email. A marketing platform might have a personal one, captured years ago through a campaign form. A loyalty system might key on phone number and nothing else. Exact match on email alone will quietly fail to link all three, and you’ll end up with three “unified” profiles for one actual customer.

    A scenario I keep seeing

    Picture a contact-centre team that’s just turned on an Agentforce service agent. A customer calls in, the agent looks up the profile, and it finds one of the three fragments, the one tied to the phone number, not the one with the full purchase history sitting under the old email. The agent answers politely and wrongly, because it was never shown the full picture. Nobody wrote a bug. The match rules just weren’t tuned for how this business actually collects data.

    This is the part people miss: identity resolution failures don’t throw errors. They just produce a confidently wrong answer, which is a worse failure mode than a system that visibly breaks.

    Why it matters more once an agent is involved

    A human service rep who gets handed a thin profile usually notices something’s off and asks a clarifying question. An agent, especially one running a scripted topic with a defined action, often doesn’t. It takes the profile it’s given as ground truth and reasons forward from there. Feed it half a customer and it will give you a confident, half-right decision.

    And the stakes go up with the kind of actions an agent takes. A recommendation engine with a fragmented profile gives you a slightly worse suggestion. An agent with write access that updates a case, applies a discount, or triggers a refund based on a fragmented profile can take an action against the wrong history entirely. Identity resolution isn’t just a data quality nicety anymore. It’s the input validation layer for everything built on top of it, and I’d put it ahead of almost anything else on the checklist before an agent gets real write access.

    Where this quietly breaks in practice

    A few patterns show up again and again.

    • Match rules left on the out-of-box defaults, never tuned against a sample of real source data before go-live.
    • Exact-match-only logic on fields that are inherently inconsistent, like name or address, where fuzzy matching or standardisation would catch far more true matches.
    • No ongoing monitoring of the unification rate, so a source system change six months later (a new form field, a renamed source object) silently degrades matching and nobody notices until someone complains.
    • Reconciliation rules that default to “most recent wins” everywhere, even for fields where a specific system should always be the trusted source, like a billing address that should come from the ERP, not whichever marketing tool touched the record last.
    • Merge and unmerge handled as an afterthought, so when identity resolution gets it wrong, there’s no clean process to split a profile back apart without losing history.

    What actually helps

    Start with a sample of real production-like data before you finalise match rules, not synthetic test records that are too clean to reveal anything. Pull a few hundred genuine customer records with the kind of inconsistency your business actually produces, and run your match rules against them by hand. You’ll find the gaps fast.

    Be deliberate about which identifiers you trust for matching and in what combination. Email alone is rarely enough once a business has more than one channel of contact. Layer in phone, and where you have it, a persistent identifier like a loyalty number or account ID that doesn’t change when someone switches jobs or email providers.

    Set reconciliation rules field by field, not as one blanket policy. Billing-sensitive fields deserve a named trusted source. Preference fields are usually fine on recency.

    And treat the unification rate as a metric worth watching on an ongoing basis, the same way you’d watch API error rates or job failures. A sudden drop after a source system change is a signal, not noise.

    Before you let an agent act on any of this

    If you’re building toward agent write access, identity resolution deserves a review of its own before that conversation even starts. Ask what happens when the agent is handed a fragmented profile: does the topic design account for incomplete data, or does it assume a fully unified customer every time? If the answer is the latter, that’s a gap worth closing before the agent goes live, not after the first wrong decision gets escalated.

    The unglamorous work pays for itself quietly. Nobody notices good identity resolution. Everyone notices the agent that got it wrong.

  • Data Cloud as the agent’s foundation: why messy data breaks Agentforce before it starts

    Every Agentforce rollout I’ve seen hits the same wall eventually, and it’s rarely the agent itself. The reasoning works. The topics are scoped sensibly. The actions call the right flows. Then someone asks the agent a simple question about a customer, and it gives an answer that’s wrong, or worse, confidently wrong. Nine times out of ten, the fault sits in the data underneath it, not in the agent.

    That’s the part nobody wants to deal with first. Data Cloud is supposed to be the unified layer an agent reasons over: one customer, one view, every interaction in context. In practice, most orgs haven’t done the work to get there. They’ve connected sources, mapped some fields, and called it done. An agent built on top of that inherits every gap, every duplicate, every stale record, and amplifies it, because now something is acting on the data instead of just displaying it.

    An agent can only act on what it can see

    A dashboard with a duplicate customer record is an annoyance. A human spots it, mentally merges the two in their head, and moves on. An agent doesn’t do that. If Data Cloud hands it two unified profiles for the same person because identity resolution didn’t match them, the agent will quite happily treat them as two different customers. It’ll miss the open case under profile A when answering about profile B. It’ll recommend a product the customer already bought, because that purchase lives in a record it never saw.

    This is the part that catches technical leads out. We’re used to building for correctness within a single transaction: get the right fields, write the right values, respect the governor limits. Agentforce changes the unit of correctness. Now it’s whatever Data Cloud assembles as “the customer,” and if that assembly is wrong, every downstream action is wrong too, even when every individual Apex action and flow behind it is written perfectly.

    Where the mess actually lives

    In the orgs I’ve worked in, the same handful of problems show up again and again:

    • Duplicate identities across sources. The same person exists as a Contact in Service Cloud, a subscriber in Marketing Cloud, and a lead from a web form, with three slightly different email addresses and no reliable match key between them.
    • Stale data masquerading as current. A nightly sync job looks fine right up until an agent starts answering questions in real time off data that’s eighteen hours old.
    • Field drift. “Active” means something different in the billing system than it does in the CRM, and nobody ever documented which one Data Cloud should trust when they disagree.
    • Siloed sources that were never meant to talk. Marketing Cloud journeys and Service Cloud cases evolved independently for years. Pulling them into one unified profile surfaces every inconsistency in how each team recorded the same kind of event.

    None of this is exotic. It’s the ordinary debt that builds up in any org that’s been customised for a decade. Reporting and dashboards tolerate that debt. Agents don’t.

    Identity resolution is the real foundation, not the agent config

    Most teams spend their setup time on the agent itself: writing topics, tuning instructions, wiring up actions. That’s the visible, satisfying part of the build. Identity resolution in Data Cloud is the unglamorous part, and it’s also the part that determines whether anything downstream actually works.

    Get the match rules wrong and you get one of two failure modes. Too loose, and the agent merges people who aren’t the same person, which is worse than a duplicate because now it’s confidently wrong about who it’s talking to. Too strict, and you’re back to fragmented profiles, with the agent missing context it should have had.

    Getting this right means sitting down with the actual source systems and asking, record by record, what a reliable match key looks like. Email alone usually isn’t enough. Phone numbers get recycled. Sometimes the best signal is a composite: email plus a loyalty ID plus a fuzzy match on name and address, with a confidence threshold someone has actually tested against real records, not just the handful used in the demo.

    What to check before an agent gets anywhere near write access

    Before any Agentforce action touches live data, I want these settled:

    • Run identity resolution against a real, messy sample of production data, not a clean subset picked to make the demo look good.
    • Pick an owning source for every field that can conflict across systems, and document it somewhere a new team member will actually find.
    • Set a freshness expectation per data stream, so you know which ones the agent can trust in real time and which ones lag.
    • Test the agent against known duplicate and edge-case records on purpose, not by accident three weeks after go-live.
    • Build a way to see exactly what the agent saw when it gets something wrong. If you can’t trace a bad answer back to the record it pulled, you can only fix the symptom, not the pattern.

    That last point matters more than it sounds. When an agent gives a wrong answer, the instinct is to tweak the prompt or the topic instructions. Half the time the actual fix sits in Data Cloud, not in Agentforce at all. Chase it in the wrong layer and you’ll burn a sprint while the real problem keeps producing the next bad answer.

    Agentforce makes data quality everyone’s problem again

    For years, data quality in Salesforce orgs has been something you clean up before a big migration or a reporting push, then let drift again once the project’s done. Agentforce removes that luxury. An agent is live, answering questions and potentially taking actions, every day, against whatever state the data happens to be in at that exact moment.

    If you’re scoping an Agentforce build right now, the honest first question isn’t which topics to configure. It’s whether Data Cloud can produce one trustworthy view of the customer, under load, on data nobody’s had time to clean up yet. Answer that first and the agent work gets a lot easier. Skip it, and you’ll spend months debugging an agent that was never the actual problem.

  • What Agentforce needs from your data model before it can work well

    Most Agentforce pilots stall in the same place. Not the agent builder, not the topics and actions configuration, but the data sitting underneath it. An agent is only as good as what it can see, and most Salesforce orgs I’ve worked in weren’t built with an AI reasoning over every field in mind. They were built for humans who knew which picklist value actually meant what, which custom field was deprecated three years ago but never deleted, and which record type nobody uses anymore.

    Agentforce doesn’t have that institutional memory. It reads the data model as it exists today, and if that model is inconsistent, duplicated, or poorly labelled, the agent gives confident, wrong answers instead of admitting it doesn’t know.

    Start with what the agent can actually see

    Every topic and action you configure in Agentforce ultimately resolves to data: a record, a field, a related list, a flow that queries something. Before touching the builder, I ask a blunt question on every engagement: if a new hire read this object’s field list with no tribal knowledge, would they understand what each field means and when it’s current?

    On a typical enterprise Service Cloud org, the answer is usually no. There’s a Status field with twelve values, four of which haven’t been used since a process changed two reorgs ago. There’s a Priority field and a separate Priority_Legacy__c field that nobody migrated off. An agent asked to summarise case urgency will happily average across both, because nothing in the schema tells it one is dead.

    The fix isn’t glamorous

    Field audits. Deprecating unused fields, or at minimum marking them clearly in help text. Collapsing duplicate meaning into a single source of truth. It’s the kind of work that never makes it onto a roadmap on its own merits, but it’s the actual prerequisite for an agent that doesn’t hallucinate case status to a customer.

    Record-level security is the agent’s permission boundary

    Agentforce runs under a user context, which means sharing rules, permission sets, and field-level security all apply to what the agent can retrieve and act on. I’ve seen teams assume the agent gets broader access than a normal user by default. It doesn’t, and it shouldn’t. If your sharing model is already a tangle of manual sharing rules bolted onto a role hierarchy that outgrew its original design, the agent hits the same gaps your human users do: able to see a case but not the account, able to read a contact but not update it.

    Before any Agentforce rollout, map which persona the agent runs as, then actually test what that persona can and can’t reach. Don’t assume it. I’ve watched a pilot fail in its first week because the agent was configured under a service account with read access to Opportunities but no access to the custom object holding renewal terms, so every renewal-related question came back empty.

    Data Cloud makes this worse before it makes it better

    If you’re layering Data Cloud underneath Agentforce to unify Service Cloud and Marketing Cloud data, the harmonisation step matters more than the AI step does. Identity resolution rules decide which records represent the same person. Get those rules wrong and you get an agent confidently merging two different customers’ order histories, or splitting one customer into three partial profiles depending on which system last touched their record.

    A typical enterprise org I’ve supported had three separate systems feeding contact records, each with its own idea of what counts as a unique customer. Before connecting Agentforce to that, the right move is weeks of validating match rules on a sample set, checking false merges and false splits by hand. That validation work is slower than the Data Cloud setup itself, and skipping it is the single most common reason agent answers come back wrong with total confidence.

    What good looks like

    • A documented identity resolution strategy, tested against real duplicate and near-duplicate records, not just the clean demo set
    • Calculated insights and segments that are actually maintained after go-live, not abandoned once the initial Data Cloud project closed
    • A named owner for data quality who isn’t the same person racing to ship the next Agentforce use case

    Actions and flows are the agent’s real API surface

    Topics get the attention in Agentforce demos, but actions are where the technical risk lives. Every action you expose is effectively an API endpoint the agent can call on its own, built on a flow or an Apex invocable method that was probably written for a human-triggered process. Those flows often have assumptions baked in: a specific picklist value gets set earlier in the user’s manual sequence, a validation rule gets bypassed because the UI never lets a person reach that state in the first place.

    An agent doesn’t share those assumptions. It calls the action with whatever inputs the conversation produced, and if the flow wasn’t built to handle unexpected or missing inputs gracefully, you get a DML error surfaced straight to a customer, or worse, a half-completed transaction sitting in the database. Every action exposed to Agentforce needs the same defensive design you’d put around a public API: input validation, bulkification, and a failure mode that doesn’t leave records in an inconsistent state.

    Sequencing the work

    The orgs that get real value from Agentforce did the data work first, usually in this order: field and object audit, sharing model validation, Data Cloud identity resolution where it applies, then action hardening. The ones that struggle configured the agent first and are now retrofitting data quality under pressure, often because a demo to leadership is already booked on the calendar.

    If you’re scoping an Agentforce rollout, weight the estimate toward data model readiness, not the agent configuration itself. I’d rather spend three weeks cleaning up a Case object and one week configuring topics than the other way round. The configuration is fast once the data underneath it can be trusted. Reversing that order just means doing the same data work later, under worse conditions, with an agent already live in front of real users.

  • Why Your Data Cloud Unified Profiles Might Be Duplicating Silently (And How to Fix It)

    If you’ve been running Salesforce Data Cloud for a while, you’ve probably hit this: identity resolution looked fine when you set it up, match rates seemed healthy, and then months later someone notices two “Unified Profiles” for the same customer — one with the old email, one with the new one. No error. No alert. Just quietly wrong data feeding into your segments and activations.

    This is one of those issues that’s small enough to get missed in QA, but expensive enough to erode trust in the whole Data Cloud investment once someone in marketing or sales spots it.

    What’s Actually Happening

    Data Cloud’s identity resolution runs on match and reconciliation rules that you define once, typically during initial setup. Here’s the part that catches people out: when you change a match rule after go-live, it does not automatically reprocess your existing, already-resolved Unified Profiles.

    Identity resolution in Data Cloud is incremental by design — new and changed source records get evaluated against the current ruleset as they come in. But records that were already unified under an older version of your match rules just sit there. They were correct under the old logic, so nothing re-triggers them.

    Common scenario:

    • You launch with match rules based on email address.
    • Six months in, you add a phone-number-based match rule to catch more matches (a very normal, well-intentioned change).
    • New records now match correctly on phone.
    • Existing profiles that could now match under the new rule — but didn’t exist yet when the rule changed — stay split into separate Unified Profiles.
    • A customer who updated their email address now has two profiles: their historical one and a new one, both technically “resolved” but never merged.

    Nothing in the UI tells you this happened. Data stream status shows healthy. Reconciliation jobs report success. The only symptom is downstream: inflated audience counts, duplicate marketing sends, or a service rep pulling up an incomplete history.

    Why It’s Easy to Miss

    • Data Cloud shows identity resolution job success/failure, not whether a rule change affected historical data.
    • Match rate metrics are calculated going forward, not against your full historical base.
    • There’s no built-in “reprocess all profiles against current rules” button that runs automatically after a rule edit — it has to be deliberately triggered.
    • Teams often treat identity resolution as “set once” configuration rather than something that needs a change-management process.

    How to Fix It

    1. Force a full reprocessing run after any match/reconciliation rule change. After editing rules, manually trigger identity resolution to reprocess against the entire population, not just new records. This is a deliberate action in Data Cloud — don’t assume it happens on save.

    2. Baseline your Unified Profile count before and after rule changes. Before changing a rule, export or note your current Unified Individual/Profile counts per key segment. After reprocessing, compare. A meaningful drop in profile count usually means more merging happened (good); a count that doesn’t move at all after adding a rule that should catch more matches is a red flag that reprocessing didn’t actually run.

    3. Build a recurring duplicate-detection check, not a one-time audit. Set up a periodic query (via Data Cloud’s Query API or a scheduled report) that looks for individuals sharing a strong identifier (verified email, phone, loyalty ID) across two different Unified Profile IDs. Run it monthly, not just after known rule changes — someone may edit a rule without realizing its downstream impact.

    4. Document match/reconciliation rule changes like schema changes. Any identity resolution rule edit should go through the same change log/approval you’d use for a data model change. Include a mandatory “reprocess triggered: yes/no” field. This alone prevents most of the silent-drift cases.

    5. Communicate the limitation to stakeholders early. When you first configure identity resolution, tell the business teams explicitly: “changing match rules later requires a reprocessing step, and we will schedule that deliberately.” This avoids the awkward conversation six months later when someone finds duplicates and assumes the platform is broken.

    The Bigger Lesson

    This isn’t a bug — it’s a design decision that makes sense for performance at scale (Data Cloud isn’t going to re-evaluate your entire customer base on every rule tweak automatically). But it’s a decision that isn’t well surfaced to admins, and the cost of not knowing about it is duplicate profiles that quietly undermine the “single customer view” that’s the entire point of the platform.

    If you’re running Data Cloud, the practical takeaway is simple: treat identity resolution rule changes as an event that requires a follow-up action, add a recurring duplicate check to your monitoring, and don’t assume “job succeeded” means “your data is fully unified.”

    Have you run into this on your own Data Cloud implementation? Reach out — always keen to compare notes on the small issues that don’t make it into the official docs.