# How to audit data quality before a Data Cloud migration Count blank match keys, conflicting emails, missing consent, and records that are not a person or an account. Identity resolution will unify what you give it. **Published:** 2026-01-12 **Canonical:** https://synconai.com/audit-data-quality-before-data-cloud-migration **Author:** SynconAI Architecture Team ## In short Before ingest, count blank match keys, conflicting emails, missing consent, and records that are not a person or an account. Identity resolution builds unified profiles from source profiles in Data 360. It does not pick a winning value or override existing data. The product is Data 360, formerly Data Cloud, and the behaviour is unchanged. Rubbish is unified faithfully. Fix the source keys, or accept the mess. ## Sources - **About Identity Resolution** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=data.c360_a_identity_resolution.htm&type=5 > Identity resolution is the processing engine that generates unified profiles from source profile data stored in Data 360. - **About Identity Resolution** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=data.c360_a_identity_resolution.htm&type=5 > Identity resolution doesn’t pick winning values or override any existing data while unifying profiles. ## What to take away - Count four defects before ingest: blank match keys, conflicting emails, missing consent, and non-party records. - Identity resolution unifies source profiles. It does not clean them. - It will not choose a survivor value or override the source. - Repair the system of record. A migration does not create a cleaner person. ## The guide The first ingest is praised because the connector finished. A week later a segment count includes a shared inbox, a switchboard number that glued an entire office into one person, and a row called "do not use" that a test once needed. Consent is blank on the people you meant to activate. Identity resolution did exactly what it is built to do. It unified the file you gave it. The file was the defect. The engine was diligent. ## What the engine will do with your file The product is Data 360. The previous name, Data Cloud, is what people still search. Salesforce rebranded it on 14 October 2025. The behaviour is unchanged. You may still see the old name in the application and in the documentation. "While the name is new, the functionality and content remains unchanged." The rename does not add a cleanser. Identity resolution is the processing engine that generates unified profiles from source profile data stored in Data 360. It is diligent. It is not a cleaner. If the source email is blank, the profile has a blank. If two sources disagree, the disagreement remains. Unified profiles are keys. They are not a golden record. The engine does not pick a winning value and does not override existing data. Salesforce states that directly: it does not pick winning values or override any existing data while unifying profiles. That is the whole audit. You are not looking for a score you can wave at a steering group. You are counting the rows that will be unified faithfully into something you cannot sell, activate, or hand to an agent. An agent grounded on those rows will sound sure. Grounding does not adjudicate a blank. Run the counts in the source systems, before the first ingest. An audit after the load tells you the same facts, later, on a meter you are already paying. The cost of that order, and of the other decisions that are cheap only before ingestion, is set out in [getting Data 360 right the first time](/insights/data-360-implementation-best-practices). ## Four counts, and what to do with each Blank match keys. Email, phone, customer number, account id: whichever keys your match rules will use. A blank key does not match. The row becomes its own profile, or it hangs off a weak rule you will regret the moment a common name or a shared building does the matching for you. Count blanks by object and by key. Fix them in the source, or exclude the row from the first ruleset and write the exclusion down where the next person will see it. An exclusion that lives in someone's memory will be "fixed" by including the row later, in the name of completeness. Conflicting emails. The same customer number with two emails, or the same email on two customer numbers that operations insists are different people. Export a sample, not only a count. Someone who knows the accounts has to say which conflicts are households, which are data entry, and which are two real people sharing an inbox. Identity resolution will not settle that argument. It will point at both values, because it does not override either source. If you need one email on the CRM contact, that is a survivor rule in the CRM, written by a person. The profile will follow whatever you keep. Missing consent. For every use you intend, especially activation, count people with a blank flag and people with a conflict between systems. Blanks are not a yes. Hold them out of any segment that leaves the org. Load the flag with the profile, not after the first campaign. A conflict is not an average and not a newest-stamp unless you have written why newest is right for that purpose. Until a person resolves it, the stricter flag stands, which means the person is held out. A migration week is when someone will propose setting blanks to yes so the count matches the old platform. That proposal is an incident. Treat it as one. Records that are not a person or an account. Test rows, queues, shared inboxes, plant, "do not use," suppliers coded as customers. These unify if you let them. They then appear in counts and, worse, in activations. Exclude them with a rule you can show, in the source, before ingest. A rule you apply only inside Data 360 after the fact will drift, because the next extract will not know about it. The source is where "do not use" has to die, or be filtered by a condition the extract always carries. ## The phone field that glues a company together One column causes more false matches than the workshop expects. A phone field full of switchboard numbers, or a mobile field where staff stored the reception desk, will relate every contact at a site to every other contact at that site. The profile looks rich. It has many names. It is one person in the ruleset and a building in reality. You will see it if you read a sample. You will not see it in a match-rate tile, and this page will not invent a rate to stand in for the sample. Shared inboxes do the same quiet damage. accounts@, info@, a family address used by three adults. Under-matching would have left them as separate profiles, which is irritating and visible. Over-matching points one profile at people who are not the same person. Nothing on a dashboard marks the profile as wrong, because it is fuller than the correct ones. Agree, with whoever owns privacy risk, what a wrong link would expose, before you add the phone key. A wrong link that puts one person's orders against another's name is a data exposure, not a quality percentage. Extra keys "just in case" widen the unify and widen the damage from a dirty column. Use the fewest keys a sample supports. A customer number both systems actually populate is a better rule than a pile of fuzzy comparisons you cannot explain. Fuzzy rules, if you use them at all, come after the exact key is understood, and only with a list of the false matches you are willing to tolerate. The place those rules live after the audit, and the fact they still do not delete the loser, is [identity resolution and duplicates](/data-cloud-identity-resolution-duplicates). ## Do not expect a survivor Teams coming from a deduplication tool expect the audit to end in a merge. That is a different job, done in the CRM, with a survivor rule a person wrote: which record remains, which fields copy, which child records reparent, what happens to activities, and how consent is kept at the stricter value. Data 360 will relate the records you keep. It will not delete the loser, and it will not stamp one email over the other. If your quality plan says "Data 360 will pick the latest email," rewrite the plan. The latest email stays in its source. The other email stays in its source. The profile points at both. Write the match keys you will actually use, and stop. Then write the attributes you will not use as keys. Free text, a job title, a country you normalised yesterday. Normalisation jobs are a particular trap. They touch every row, they win on recency, and they change nothing a customer would recognise. They are not a quality programme. They are a write. If you let recency pick a winner anywhere, do it in the CRM under a rule, not by imagining the unify step will notice. Zero copy is federation, not a latency promise, and it is not an audit. Connecting the source with zero copy data federation leaves the bytes where they are, which is useful. It does not count your blanks for you, and it does not make a dirty key clean by avoiding a copy. Run the four counts on the lake or the CRM before you federate it into a segment. A federated mess unifies as faithfully as a copied mess. You have only saved the storage. Tableau Next does not replace Tableau, and neither of them is the audit. A chart of the blanks is useful after you have the count. It is not a substitute for excluding the row. ## A sample beats a percentage Pull fifty source rows before the first load, or fifty unified candidates after a dry run on data you can throw away: the blanks, the conflicts, the missing consent, the non-people. Read them with the person who owns the source. A figure without a sample gets explained away. A shared inbox in the sample does not. Do not publish a match percentage from that exercise. Publish the counts and the decisions. This page has no match rate to lend you, and a borrowed one would describe someone else's keys. Set a bar to start, in counts you can re-run. No shared inboxes in the ingest. Consent populated for anyone you might activate. A named owner for the open email conflicts. You can migrate with open conflicts if you have decided not to activate those people and the decision is written down. You should not migrate while pretending the engine will choose. | Defect | What you count | What identity resolution will do | What you do | | --- | --- | --- | --- | | Blank match key | Blanks by object and by key | Leave the row unmatched, or hang it off a weaker rule | Fix the source, or exclude the row and write the exclusion | | Conflicting email | Pairs, plus a sample a person reads | Point at both values. It will not pick one | A CRM survivor rule if one CRM email must remain | | Missing or conflicting consent | Blanks and disagreements, by purpose | Keep both assertions. It will not merge them into a yes | Hold the person out until a person resolves it | | Not a person or an account | Test rows, queues, shared inboxes, suppliers | Unify them if you ingest them | Exclude them in the source extract, with a rule you can show | ::: warn Do not backfill a yes to make a segment look complete, and do not add a phone key to lift a match you have not sampled. The engine will unify the rubbish faithfully. A fuller profile is not evidence the rubbish was cleaned. ::: ## The bar, written down The audit is finished when four sentences exist, each with a count and an owner. How many blank keys you will still ingest, and why those rows are excluded from activation. How many email conflicts remain open, and who may close them. How many people lack consent for the use you intend, and the confirmation that blanks are held out. How the extract drops non-people, in a condition someone else can re-run. A new source resets the bar. It brings its own blanks, its own shared mailboxes, and its own test rows. Re-run the four counts on that source before you add it to a ruleset. A clean CRM extract does not vouch for a lake you connect the following month. Put the re-run on a calendar. Sources rot. A list import lands without country codes and a phone rule starts gluing a market together. A test record comes back because a sandbox refresh copied it. Nothing in the platform pages you to say the four counts moved. The owner re-runs them. An hour, on a cadence you can keep, is the operating model. A one-time audit at kickoff is a souvenir. Then ingest the rows that pass the bar. Not the estate. The first object, with the keys you counted. If the dry run's sample is still nonsense, you have learned the only thing the migration needed to learn, and you have learned it before the meter and the segment. That is a successful audit. Treating it as a delay, and loading anyway, is how the shared inbox reaches a customer. ## Questions ### Will identity resolution clean duplicates during migration? It builds unified profiles from source profiles. It does not pick a winning value or override existing data. Dirty sources produce a profile that points at the dirt. The profiles are keys, not a golden record. Cleaning a survivor, if you need one CRM row, is a separate job in the CRM. ### Which defects should we count first? Blank match keys, conflicting emails, missing consent, and records that are not a person or an account. Count them in the source before the first ingest. A count after the load is the same news, later, on a meter you are already paying. Read a sample with the person who owns the source. A figure without a sample gets explained away. ### Can we fix quality inside Data 360 after the load? You can exclude rows and you can stop activating them. The durable fix is in the system of record. The engine will not overwrite the source with a survivor value. A formula that secretly picks an email creates a third version the CRM does not agree with. Do the survivor work in the CRM, then ingest what you kept. ### Is a blank consent a yes? No. Hold those people out of activation. Load consent with the profile. Do not backfill a yes to make a segment look complete. A blank has no source and no time, so it cannot be defended when another system disagrees. Until a real assertion exists, the person stays out. ### What is the product name on the far side of the migration? Data 360. Data Cloud is the former name. The rebrand was 14 October 2025, and the behaviour of identity resolution is unchanged: unified profiles from source data, without overriding that data. You may still see the old name in the application and the documentation. The name change does not add a cleanser. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Data 360 (https://synconai.com/salesforce-data-360-services.html).