CRM Data Integrity: How to Audit It, and What the CRM Cannot Fix
CRM data integrity means records that are complete, consistent and trustworthy. Here's how to audit it — and which problems arrive already made.
CRM data integrity means the records in your CRM are complete, internally consistent, non-duplicated and traceable to a source you trust. Auditing it means measuring those properties on real records rather than asserting them from a policy.
The CRM can fix most of what an audit finds. It cannot fix one category: fields that arrive already formed from somewhere else. Campaign, source and medium values are written by marketing systems before the record ever reaches the CRM, and a validation rule can reject a bad one without being able to produce a correct one.
What CRM data integrity means
Records that are complete, consistent, non-duplicated and traceable.
Salesforce’s definition of data integrity (accessed 2026-09-11) covers the general property; in a CRM it resolves to four checkable things:
- Complete. The fields a process depends on are populated, not optionally populated.
- Consistent. The same fact is recorded the same way across records and objects.
- Non-duplicated. One real entity, one record, with a defensible merge history.
- Traceable. You can say where a record came from and when.
The fourth is the one most CRM hygiene work skips, and everything below turns on it.
The four types of data integrity
Entity, referential, domain and user-defined integrity.
| Type | What it guarantees | In CRM terms |
|---|---|---|
| Entity | Every record is uniquely identifiable | No duplicate accounts or contacts |
| Referential | Relationships between records stay valid | No contacts pointing at deleted accounts |
| Domain | Values fall within a permitted set | Picklists, not free text, on fields you filter by |
| User-defined | Business rules specific to you hold | Required fields, stage-gating, ownership rules |
The first three are enforceable by the database. The fourth is enforceable by configuration. None of the four says anything about whether a value is correct — only whether it is well-formed, unique, permitted and rule-compliant. A campaign source of paidsocial passes every one of these tests while being the wrong value.
Running the audit
Measure four properties on a real sample: duplication, completeness, conformity, staleness.
Do this on actual records, not on the schema. New Breed’s CRM optimization framing (accessed 2026-09-11) sets out the surrounding program; the checklist below is what to measure.
| Property | How to measure it | What the number tells you |
|---|---|---|
| Duplication | Matching records on email, then on company and name | How much of your pipeline is counted twice |
| Completeness | % populated, per required field, per object | Which fields are required in name only |
| Conformity | % of values in a field that match the permitted set | Whether picklists are enforced or advisory |
| Staleness | % of records not touched in N months | How much of the database is fiction |
| Provenance | % of records where the creating source is recorded | Whether any of the above can be traced to a cause |
Take a sample of a few hundred records per object rather than the whole database; the proportions hold and the exercise finishes in a day. Run it on a fixed schedule and compare against itself: an absolute figure means little, a trend means everything.
The fifth row is the one that turns an audit into a diagnosis. The first four tell you what is wrong. Provenance tells you where it came from, which is what decides whether the CRM can fix it.
The quality dimensions behind the audit: Data quality explained — accuracy, completeness, consistency, and how they are measured.
Governance inside the CRM
Field ownership, required fields, picklists and validation rules.
Everything the CRM can do about integrity, it does here:
- Name an owner per field. Someone who can say what it means and approve a new permitted value.
- Make required fields actually required, at the point of save, rather than in a report of exceptions nobody reads.
- Replace free text with picklists on every field you filter, group or report by.
- Write validation rules that reject malformed values at entry.
- Set a deduplication policy and run it on a schedule, not after an incident.
Insycle’s treatment of CRM data integrity (accessed 2026-09-11) covers this practice set in depth.
Done properly, this is genuinely effective, and it has a hard boundary. Every item on that list governs what the CRM accepts. None of them governs what the upstream system sends.
What the CRM inherits
Campaign, source and medium values are written elsewhere and arrive already formed.
“Half the audit findings are the CRM’s to fix. The other half come back next quarter because nothing upstream changed.” — Rob Allanach, Sr. Solutions Architect, Claravine
That split maps cleanly onto the audit above.
| Field | Where it is authored | Can the CRM fix a bad value? |
|---|---|---|
| Contact name, title, phone | In the CRM, by a person | Yes — validate, enrich, correct |
| Account hierarchy | In the CRM, by ops | Yes — a modeling decision you own |
| Lifecycle stage | In the CRM, by process | Yes — rules and stage-gating |
| Campaign | The ad platform or campaign manager | No — it arrives formed |
| Source / medium | The link that produced the visit | No — set before the record existed |
| Original channel | The tagging at campaign setup | No — and it cannot be reconstructed |
Every row in the lower half is a field the CRM receives rather than creates. A validation rule can reject paidsocial for not being on the picklist, and the record is then either blocked, defaulted or filed under Other. None of those is the correct value, because the correct value was decided in a different system by a different team and is not recoverable from anything the CRM can see.
This is why the same findings recur. The audit reports them, the team fixes what it can, and the next quarter’s records arrive with the same defects because the thing producing them did not change.
Where campaign values come from: UTM parameters explained — what each parameter does and how they are built.
Fixing upstream vs rejecting downstream
A validation rule protects the CRM; it does not produce a correct value.
The distinction is worth being precise about, because both are legitimate and they solve different problems.
Rejecting downstream keeps bad data out of a system. It is defensive, it is fully within CRM ops’ control, and its output is a blocked or defaulted record plus, if you are lucky, an error somebody sees. What it cannot do is turn a wrong value into a right one.
Fixing upstream means the value is correct when it is created: the campaign manager selects from an agreed list at setup, so what arrives at the CRM was never wrong. It is not within CRM ops’ control, which is exactly why it does not happen, and it is the only intervention that removes the recurrence rather than catching it.
One team described the difference in practice.
“I know that the CID is delivered. I don’t have to struggle with a very manual Excel spreadsheet. The switch from managing this manually to one true source of truth—where you can actually validate and have governance involved—beats everything hands down. So I really love what the tool does for me.” — Mary Daniel, project administrator, Vanguard
Validate and have governance involved are two things, not one. Validation is the downstream check; governance is the upstream agreement that gives validation something correct to check against.
See standards enforcementPermitted values applied where records are created.Explore Claravine Data StandardsFrequently asked questions
What are the four main types of data integrity?
The standard set covers uniqueness, valid relationships, permitted values and your own business rules. All four govern whether a value is well-formed; none governs whether it is correct.
What are the 5 principles of data integrity?
Attributable, legible, contemporaneous, original and accurate. The framing comes from regulated-industry record-keeping and transfers usefully: attributable is provenance, and it is the one CRM audits most often omit.
What is CRM in data?
The system of record for customer and prospect relationships. It is a consumer of marketing data as much as a producer of its own, which is the distinction this page is built on.
What are the four pillars of a CRM?
People, process, technology and data. The fourth is the one that decays, because the other three can be correct while the records arriving are not.
What is a CRM governance framework?
The field ownership, required fields and validation rules that keep the CRM’s own records correct. It governs what the CRM accepts; it does not govern what upstream systems send.
Sources
- Salesforce, “What Is Data Integrity?” (accessed 2026-09-11) — the category definition.
- Insycle, “Data Integrity for CRM Data” (accessed 2026-09-11) — CRM-specific integrity practices.
- New Breed, “What is Data Integrity? A Framework for CRM Optimization” (accessed 2026-09-11) — the audit framing.
