# CRM data rules

Establish how a record is identified and when it may change. Fast automation can multiply inconsistent data if identity, precedence and ownership remain implicit.

Revision: 2026-09-24

## When to use it

Before importing contacts, enriching records or updating opportunities through integrations and AI assistants.

## Expected output

Rules for each CRM object covering identification, editable fields, value sources and a conflict resolution path.

## 1. Identify the right record

Define contacts, companies and opportunities separately. Similar names can suggest a review, but must not determine a merge by themselves.

### Objects and identifiers

Record involved objects, stable keys and relationships between contacts, companies and opportunities.

________________

### Matching rules

Specify exact comparisons, normalisation and cases where multiple candidates require review.

________________

### Duplicates and merging

Describe who may merge records, which values survive and how activity history and relationships are preserved.

________________

> Illustrative example, replace with your own: Illustrative example: two contacts have similar names but different email addresses. Automation suggests a review rather than merging them or replacing their activity history.

## 2. Govern updates

Identify the authoritative source for every field. Distinguish values observed in a document from inferences, and prevent missing inputs from erasing verified information.

### Field, meaning and allowed values

Define format, requirement, permitted values and the operational meaning of sales stages.

________________

### Source and precedence rule

Specify when email, a form, an external system or a manual edit may update the field.

________________

### Allowed and approved writes

List automatically editable fields, protected fields and conditions requiring the owner’s confirmation.

________________

> Illustrative example, replace with your own: Illustrative example: a message with no phone number does not clear the existing field. A proposed new deadline becomes a note for approval, not a silent update.

## 3. Check conflicts and effects

Plan for concurrent edits and repeated delivery of the same event. Protect work done by people after the workflow began.

### Repeated events and concurrent edits

Describe how processed events are recognised and how the workflow checks whether the record has changed.

________________

### Trail and correction

Record reference, previous value, proposal, source and actor; define access and correction methods.

________________

### Periodic checks and owner

Specify checks for duplicates, empty fields, inconsistent stages and cases awaiting review.

________________

> Illustrative example, replace with your own: Illustrative example: a salesperson changes the stage while AI prepares an update. The workflow detects the new state and routes the conflict for review instead of overwriting it.

## Pitfalls to avoid

- Merging contacts based only on similar names.

- Overwriting verified data with an inference or missing input.

- Treating a successful write as sufficient without checking record relationships and state.

Stolen Orbit — https://stolenorbit.com/en/templates/crm-data-rules/