# CRM data hygiene and field governance

> Canonical page: https://wayhatch.com/workflows/crm-data-hygiene/
> Evidence label: Conceptual blueprint with a synthetic example, full guide. Definitions: https://wayhatch.com/about/evidence-labels/
> Updated: 26 October 2026 (2026-10-26). Publisher: wayhatch, wayhatchai@gmail.com
> Team: RevOps · with Sales

A monthly review of the fields your reports depend on, fixed with each record owner and traced back to the process that broke them.

## Outcome

A short field dictionary for the fields your reports depend on, and a monthly review log: findings, the fix agreed with each record owner and one process change. RevOps acts as data steward; record owners correct their own records.

## Downloads

- [Field dictionary template](https://wayhatch.com/downloads/crm-field-governance-template.md): Governance and review checklist, Markdown · 4 KB
- [Synthetic example](https://wayhatch.com/downloads/crm-hygiene-example.md): Invented company, Markdown · 7 KB
- [Fictional record extract](https://wayhatch.com/downloads/crm-hygiene-input.json): The example’s inputs, JSON · 3 KB

## Before you start

- A named data steward in RevOps with access to CRM setup and reports.
- Agreement from the Sales leader on stage definitions and record ownership.
- A list of the reports and forecasts leadership actually reads.
- A place for the field dictionary that Sales and RevOps can both read.

## Inputs

| Input | What it provides | If missing |
| --- | --- | --- |
| Reports in use | Forecast, pipeline and board views | Ask the Sales leader which are read |
| Field metadata | Type, picklist values, validation rules | Export from setup; note gaps |
| Record extract | Critical fields, owner, last write source | Say which records were left out |
| Stage definitions | Entry criteria, required fields at stage | Draft them with Sales first |
| Write sources | Forms, imports, integrations | Mark the source as unknown |

## Steps

1. **Choose the critical fields** (RevOps with Sales leader). Start from the reports leadership reads and list the fields they depend on. Keep the list short. Give each field a definition, allowed values, an owner and the roles that may edit it. If nobody will own a field, leave it off the list.
2. **Write the rules into the CRM** (RevOps). Turn the definitions into picklists, validation rules and required fields at stage. Restrict edit rights on fields that feed the forecast. Test each rule in a sandbox or on a copy, and write down the exceptions it must allow, such as paused deals or migrated records.
3. **Run the monthly check** (Data steward or assistant). Export open records with the critical fields, the owner and the last write source. Flag likely duplicates, past close dates, missing next steps and values outside the picklist. Treat each flag as a question for the owner until they confirm it.
4. **Fix each record with its owner** (Record owner). Send each owner the list for their own records. Owners correct the values they know. RevOps runs a duplicate merge only after both owners agree which record survives. Close dates and amounts change only with the owner’s agreement.
5. **Change the process behind the errors** (RevOps with Sales leader). Group the findings by source: an import, a form, an integration or a manual habit. Choose one cause per review and change the rule, permission or template behind it. Record the change in the dictionary and look for the same pattern next month.

## Automation candidates

| Candidate | Needs | Watch for |
| --- | --- | --- |
| Flag past close dates | Stage and close date fields | Deals paused by the buyer |
| Suggest duplicate pairs | A reliable matching key | Subsidiaries, shared domains |
| Map free text to picklist | Approved mapping table | Values with no clear match |
| Send each owner their list | Owner field, destination | Unassigned or departed owner |

## Where an agent could help

Compare records against the field dictionary and propose duplicate pairs, picklist mappings and owner lists, citing the rule each flag breaks. Merges, deletions and changes to forecast fields stay with people.

## Human review

- Both owners confirm before a duplicate merge.
- Record the surviving ID and what history moves.
- Owners agree changed close dates and amounts.
- Test new validation rules before switching them on.
- Approving fixes does not approve deleting records.

## Limitations

- No integration, script or agent has been built for this workflow.
- No time savings or data quality results are reported.
- Merge behaviour and validation options differ by CRM; check yours before changing rules.

## If you pilot it, measure

| Measure | How |
| --- | --- |
| Field completeness | Open records with every critical field filled |
| Stale close dates | Open deals dated in the past, per review |
| Repeat findings | Same pattern in consecutive reviews |
| Owner follow-through | Flags resolved by the next review |
| Rule exceptions | Valid records a new rule blocked |

Next workflow: [Sales-to-Customer Success handoff](https://wayhatch.com/workflows/sales-to-cs-handoff/)