Skip to content

Data Quality & Governance

Part of: ClientVerse Core (every client).

What it is

Three capabilities that between them answer "is the data any good, and who says so":

  • Data Quality Monitoring scores Contact, Account and Opportunity nightly and raises an issue when a record falls short.
  • Enrichment proposes corrections for a human to accept or reject, rather than writing them.
  • Governance policies define how long records are kept and what happens when that expires.

They are separate permission areas because firms staff them differently — the person who works a data-quality queue is rarely the person who sets a retention policy.

Who it's for

Admins and data stewards. End users feel the results — fewer duplicates, fuller records — but do not operate any of it.

Data Quality Monitoring

A scheduled nightly batch computes a weighted 0–100 quality score per object from field completion, activity recency, and open-duplicate flags. Each run writes a Data_Quality_Score__c snapshot: the overall score, per-component scores, records evaluated, and how many failed each component. Records that fall short raise a Data_Quality_Issue__c.

Weights and thresholds are entirely custom-metadata driven, so re-weighting a component or moving a threshold is configuration, not a release. The active weights per object are enforced to total 100, so the score always reads as a true 0–100 scale.

Alerts fire to the Data Manager audience — in-app and email — when a score drops below a configured minimum or falls more than a set number of points week over week.

Treat Data_Quality_Issue__c as a work queue, not a report. Assign the issues and watch whether the queue drains. A queue that only grows means the scoring is miscalibrated or nobody owns the work, and either way the dashboard will keep looking bad without telling you which.

Enrichment

Enrichment writes an Enrichment_Proposal__c — the field, the current value, the proposed value, the source, and a confidence — for review. It does not update the record.

That is a deliberate choice: an automated correction that is right 95% of the time still puts wrong data into a client-facing system 1 time in 20, and nobody can tell afterwards which is which. Review the proposal queue on a regular cadence; unreviewed proposals are the same problem as unworked issues, just quieter.

Governance policies

A Governance Policy (Governance_Policy__c) sets, per object and record type, how many months of inactivity trigger an action — archive the record, or delete it. A nightly batch finds records past the window, applies the action, and writes an immutable audit entry to Clientverse_Log__c including a JSON snapshot of the record's field values at the time of action.

Governance_Settings__c holds the org-level switch and the last run date. Admins can preview how many records a policy would affect before saving it — use that every time.

Introduce a new policy in a sandbox first, against real data volumes. A policy that fires on a large fraction of existing records generates more work than the firm can absorb, and the preview is what tells you that before the batch does. The audit snapshot means an archive is recoverable; a delete is not.

How to use it

  1. Start with monitoring, not policy. Let the scores run for a few weeks before setting any retention rule — you need to know what normal looks like.
  2. Calibrate weights and thresholds so the alert means something. An alert that fires constantly is an alert nobody reads.
  3. Assign an owner to the issue queue and the proposal queue. Both are only useful if someone works them.
  4. Add governance policies last, previewing each, sandbox first, archive before delete.

Sequence matters after a migration. Load data first, then let quality and enrichment run. Running them mid-load raises issues against records that are still incomplete by design, and buries the real ones.