# Where Data 360 programmes stall > Six months in, three sources connected, profiles building nightly, and the service team still opens the legacy system to check an address. Nothing failed. Nothing is used either. - Source: https://synconai.com/insights/data-360-implementation-challenges - Publisher: SynconAI (https://synconai.com) - Desk: Data & Integration - Author: SynconAI Delivery Team, Consulting & implementation - Published: 23 February 2026 - Updated: 29 August 2026 - Reading time: 11 minutes - Topics: Data 360, Identity Resolution, Data Quality, Troubleshooting, Governance ## Key points - A stalled programme rarely shows an error. It shows a team quietly opening the source system instead of the profile, which is the only signal you get. - Loose identity resolution is a data exposure, not a data quality defect, because a wrong merge looks healthier than a correct profile and nothing flags it. - When nobody owns the match rules they get tuned by whoever picked up the ticket, and the ruleset stops being a decision and becomes a sediment of fixes. - Recover in one order: freeze scope, restore trust in one narrow profile, then widen. Widening first is how a one-use-case problem becomes a five-use-case problem. --- Six months in, three sources connected, unified profiles building nightly, and the service team still opens the legacy billing system to check an address. Nothing has failed. No pipeline is red, no job is erroring, the platform is doing exactly what it was configured to do. It is simply not being used, and nobody has said so out loud. That is what a stalled [Salesforce Data 360](https://www.salesforce.com/data/) programme looks like from the inside, and it is why these are harder to rescue than outright failures. A failure produces an incident and an owner. A stall produces a status report that says amber for four months running. This is the diagnostic companion to [the decisions made before ingestion](/insights/data-360-implementation-best-practices). That piece is for programmes that have not started. This one is for programmes already underway, where the connectors ran, the profiles exist, and something is quietly wrong. Data 360, which most organisations still have written into their documentation as Data Cloud, gives you very few error messages at this stage, so the diagnosis has to come from behaviour rather than from the platform. Below are the six stall points we meet most often, each with the observable signal that tells you it is yours. ::: takeaways Stalls announce themselves through behaviour, not errors: people opening the source system, a match rate nobody can explain, five use cases and no delivery. Diagnose from the signal, then freeze scope, restore one narrow profile, and widen only from something that works. ::: ## Read the signal, not the status report | Signal you can observe | Likely cause | First recovery move | | --- | --- | --- | | Profiles build nightly, teams still open the source system | No team ever accepted the profile as authoritative for a decision | Ask one team, in writing, what would have to be true to stop checking | | A profile holds attributes that cannot belong to one person | Match rules loosened without evidence, producing silent false merges | Freeze the ruleset and read fifty merged profiles by hand | | Match rules changed and no one can say who decided | No named owner for identity resolution | Name a person before the next tuning change lands | | Match rate moved and nobody knows when or why | A source system changed shape upstream without notice | Compare the current source schema against what the mapping expects | | Five use cases in flight, none delivered | Scope grew without the prerequisites being re-scored | Freeze new scope, finish the one closest to done | | The sponsor asks what improved and receives a demo | No baseline captured before ingestion | Measure the current state now, before any further change lands | The third column is the first move, not the remediation. Each one is designed to confirm or eliminate a cause within a day, because the expensive mistake in a stalled programme is committing a quarter to the wrong diagnosis. ## Stall one: ingestion succeeded and nobody trusts the result The most common stall, and the one most often reported upward as a communications problem. Profiles exist. Adoption does not. **The signal.** Watch what a service agent actually does when a customer rings. If the unified profile is open in one tab and the source system is open in another, the profile has not been trusted, whatever the adoption dashboard says. The same tell appears in marketing when a segment is built in Data 360 and then reconciled against a spreadsheet exported from the old tool before anybody presses send. **What is underneath it.** Trust was assumed to arrive with the pipeline. In practice it is granted per attribute, per screen, per team, and it has to be asked for. Nobody sat with the service lead and said: here is the address we will show you, here is where it came from, here is what happens when the billing system and the portal disagree. Without that conversation the agent has no basis for preferring the profile, and checking the old system costs them almost nothing. There is usually a second layer underneath. Ask which attribute they distrust and you rarely get "all of it". You get one: the phone number, or the entitlement, or the last order date. One visibly wrong attribute on a screen discredits the other twenty, because the agent has no way to tell which parts of the record are reliable and which are not. ::: tip Fix the attribute they name, then show them it is fixed, before attempting anything broader. Trust in a unified profile is rebuilt one field at a time, and the field that matters is the one they can point at rather than the one with the worst quality score. ::: **Recovery.** Pick one team, one screen, and the smallest set of attributes that team needs to make one decision. Write down what trusted means for each of those attributes: which source wins, what happens when it is empty, and how stale it is allowed to be. Then prove it against real records with the team in the room. That is a narrow win, and narrow is the point. ## Stall two: identity resolution loosened until the merges went wrong Under-matching is loud. Somebody complains that the agent cannot see an order, and the rule gets relaxed. Relax it a few times, each time for a reasonable-sounding ticket, and the ruleset crosses a line nobody marked. **The signal.** Look for attributes that cannot coexist on one human being. Two dates of birth. Two national identifiers. Addresses on different continents with nothing in the interaction history to explain it. Consent recorded twice with opposite values. Watch also for a profile count that dropped noticeably between releases with no migration to account for it, which is a merge event wearing the costume of an efficiency gain. **Why this one is different.** Identity Resolution failures are not symmetrical, and the asymmetry is the whole point. Under-matching leaves one customer sitting as three profiles: visible, irritating, reversible. Over-matching fuses two real customers into one, and it is silent. The merged profile looks better than the correct ones, because it has more attributes populated and a richer history. Nothing on a dashboard distinguishes it from a good match. ::: warn A false merge is a data exposure event. One customer can be shown another person's order history, and a suppression or consent flag set by one individual can silence or authorise a stranger. Treat a suspected over-match as a privacy incident and route it accordingly, rather than as a backlog item for the data team. ::: **Recovery.** Freeze the ruleset before doing anything else, because every further tuning change makes the population harder to reason about. Then read fifty merged profiles by hand, chosen deliberately rather than randomly: shared household email addresses, generic business mailboxes, common surnames, records that arrived through a migration. Build a labelled set of record pairs, some that must match and some that must not, so the next loosening can be tested rather than argued about. That set is the asset the programme should have had from the start, and building it late is still far better than not building it. ## Stall three: no owner, so the match rules are tuned by whoever holds the ticket Ask who decided the current match threshold. In a stalled programme the answer is a release note without an author. **The signal.** Match rule changes appear in the deployment history with no accompanying decision, no test evidence and no name against them. Ask three people why the email rule was relaxed and get three different recollections. Ask what the rule was six months ago and watch somebody open a diff to find out. **What is underneath it.** Identity resolution looks like configuration, so it gets treated like configuration: a setting an administrator adjusts in response to a request. It is not configuration. It is a business decision about whether two records describe the same customer, and only the process owner can answer that for their purpose. Left to a queue, the ruleset stops being a design and becomes a sediment of individually reasonable fixes, each one loosening slightly, none of them ever reviewed together. **Recovery.** Name one person accountable for the ruleset, with the authority to refuse a change. Give them two numbers to watch and nothing else: match rate over time, cut finely enough to see a single market or a single source move on its own, and the merge and split rate month over month. Any change to the rules gets a stated reason, a run against the labelled pair set, and a name against it. Once it exists this is about an hour a month, and no amount of tooling substitutes for it. ## Stall four: the sources kept changing and nobody told the upstream teams Data 360 sits downstream of systems whose owners have often never heard of the programme. A vendor normalises casing on export. A field gets repurposed. A migration reissues customer identifiers, so yesterday's customers arrive today as new ones. **The signal.** The match rate moved and nobody can date the change. Or one market's match rate fell while the others held, which almost always means one source, one format and one upstream release. Profile counts rising faster than the business is acquiring customers is the same story told the other way round. **What is underneath it.** Nothing in the platform announces this. The connector still runs green, because the shape it receives is still valid, just different in meaning. The [published connector range](https://www.salesforce.com/data/connectivity/data-cloud-connectors/) makes adding a source easy, and easy is precisely what lets a source be added without anybody establishing a relationship with the team that owns it. **Recovery.** Compare the current source schema, and a sample of current values, against what the mapping expects. Then do the organisational half, which is the part that actually holds: get the programme onto the change advisory path of every system feeding it, and give each source a named contact on both sides. Treat every new connector as a change to identity resolution rather than an addition to a list, because a new source brings new identifier formats and a new population, and re-run the labelled pairs before it goes live. ## Stall five: scope grew from one use case to five without re-scoring The programme was funded for service. Then marketing asked for segmentation, then finance wanted a view of arrears, then somebody mentioned an agent. Each addition was individually sensible and none of them was re-scored against what it required. **The signal.** Five use cases in flight and none delivered. The steering group agenda covers all five every fortnight and none of them advances. New requirements arrive faster than existing ones close, and the delivery team can no longer say which use case a given piece of work belongs to. **What is underneath it.** Every use case carries its own prerequisites: a definition of the entity it needs, an attribute-level source of truth, a tolerance for staleness, a consent position. Adding a use case adds a set of decisions, not a set of reports. When the first use case has not yet earned trust, the second inherits its unresolved questions and contributes its own. That compounding is why stalled programmes feel busier than delivering ones. Which candidates are genuinely worth taking, and in what order, is set out in [what Data 360 is actually good for](/insights/data-360-use-cases). **Recovery.** Freeze new scope explicitly and visibly, at sponsor level, so it reads as a decision rather than as a delivery team's reluctance. Then finish the one closest to done, even where it is not the most valuable one, because a programme that has shipped nothing needs a delivery more than it needs the right delivery. ## Stall six: no baseline, so value cannot be proved The sponsor asks what improved. The programme responds with a demonstration of the platform. Everybody in the room understands what has just happened. **The signal.** Ask for the number that was true before ingestion started: average handle time on the affected queue, the duplicate rate in the CRM, the share of campaigns that needed a manual list reconciliation. If producing that number would take a project, no baseline was captured, and the programme has no way to distinguish improvement from the ordinary variation of a business. **What is underneath it.** Baselines feel like overhead at exactly the point when everybody is confident, which is the point at which they are cheapest to capture. Retrofitting one later means the starting number gets measured on a partly-changed system, which is the one number you most needed for comparison. **Recovery.** The original baseline cannot be recovered, so stop trying and measure now, before any further change lands. Two or three operational numbers the business already recognises will beat a data quality index the business has never seen. Then hold the measurement still while you make one change at a time, which is the same discipline that makes AI work assessable and fails for the same reasons set out in the [Agentforce diagnostic](/insights/agentforce-implementation-mistakes). ## Recover in one order: freeze, restore, widen Most stalled programmes have three or four of the six at once, and the instinct is to attack the most damaging one. That is the wrong sequence, with a single exception. **Stop the bleeding first.** Freeze new scope and freeze the match rules. Nothing else on this list can be diagnosed while the population and the requirements are both moving, and a frozen programme is not a paused one: it is one where the next change is attributable. The exception is a suspected false merge, which is a live exposure and gets handled immediately, in parallel, through whoever owns privacy risk. **Then restore trust in one narrow profile.** One team, one screen, a handful of attributes, written definitions, proved against real records with the team watching. Not a data quality programme across the estate, and not a relaunch. The mechanics of how the platform assembles and serves that profile are set out in Salesforce's [overview of how it works](https://www.salesforce.com/data/how-it-works/), but the work at this stage is agreement rather than configuration. **Then widen, from something that works.** Add the second team, then the second use case, re-scoring the prerequisites each time rather than assuming they are inherited. Widening before restoring is how a one-use-case problem becomes a five-use-case problem, and it is the single most common thing we are called in to unwind. The programmes that recover are not the ones that fixed the most. They are the ones that stopped adding, proved one narrow thing, and let that be the argument for the next increment.