Stolen Orbit
ENIT
Let’s talk
FREE TEMPLATE · FILL IN, DOWNLOAD, REUSE

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.

By Stolen OrbitRevision

When to use it and what to produce

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

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

Fill in the fields below and download your document. The website does not send or save answers: closing the page may lose them. Examples are illustrative and should be replaced with your process data.

Download the complete blank template (.md)

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.

See a worked example

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

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

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

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

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.

See a worked example

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.

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

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

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

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.

See a worked example

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.

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

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

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

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.

Take the next step together.

Use this document to start a discussion about scope, evaluation and project ownership.

Review the text before sending. Only your email is needed alongside the message; other details are optional.