CRM Data Contract: Name Every Field, Owner, Source, and Staleness Rule

CRM data is the structured information a customer relationship management system keeps about organizations, people, commercial work, and interactions. A CRM data contract is the field-level agreement that makes that information operable: it states what every active field means, where it belongs, who is accountable for it, which source may write it, when the value becomes stale, and what happens when the rule fails. Without that agreement, a CRM is shared storage with private interpretations.

CRM data needs an agreement, not a larger inventory#

Salesforce’s CRM database overview lists the kinds of information commonly held in CRM records: contact details, communication and purchase history, service requests, preferences, and commercial status. A B2B implementation will usually distribute those facts across organization, contact, deal, activity, and service objects rather than one flat customer row.

CRM data is not synonymous with all customer data. A CRM primarily coordinates known relationships and direct work by sales, marketing, and service teams. A customer data platform is designed to unify a broader set of data from multiple sources into customer profiles. Salesforce’s CRM and CDP comparison describes that directional difference, while also treating the systems as complementary. Product boundaries overlap, so define the actual source and consumer instead of relying on a category label.

A schema describes the shape of the data: objects, fields, types, required values, and constraints. A data dictionary helps people look up those elements and their meanings. A data contract contains the schema and definitions, then adds commitments about producers, consumers, ownership, quality, service levels, and change. The Open Data Contract Standard makes those additional concerns explicit.

There is no canonical formula for CRM data or a CRM data contract. Completeness and duplicate rates can be calculated, and a system can evaluate whether a value is older than a locally approved limit, but those measures do not define the contract. There is also no defensible universal benchmark for a good CRM-wide fill rate, duplicate rate, or update cadence. A date of birth and a job title do not decay on the same clock; a deal state and a legal company identifier do not become unusable for the same reason.

The UK Government Data Quality Framework defines quality as fitness for purpose and says timeliness depends on whether the lag is appropriate for the intended use. That is the right basis for a staleness rule: the consequence of acting on an old value, not a borrowed calendar interval.

The deliverable is one contract row for every active field#

“Every field” means every property that a person, workflow, integration, export, model, segment, or report may actively write or consume. It includes vendor-default fields when your operation depends on them. It does not require documenting thousands of unused product properties as though they were part of your business model; unused fields should be identified as out of scope, hidden, or retired under a controlled decision.

Build one row per active field. Keep the artifact in a table, catalog, or versioned file that the people configuring and consuming the CRM can actually reach.

This is the minimum practical answer to “What should a CRM data contract include?” The full ODCS model is deliberately broader. A lean CRM team should keep only the metadata and controls it can maintain, but it should not omit meaning, authority, freshness, or consequence from a field that drives a decision.

Step 1: trace decisions before exporting properties#

Start with a decision or action that currently depends on CRM data. Examples include assigning an inbound account, advancing an opportunity, suppressing an ineligible contact, forecasting an open pipeline, or routing a service issue. For that one use, name:

• the person or system that consumes the result;
• the object and record grain involved;
• every field and relationship used to make the decision;
• every form, import, workflow, integration, and manual role that can write those values;
• the output produced when the values pass; and
• the operational consequence when they are missing, conflicting, or old.

Then export or inspect the relevant property definitions and reconcile the implementation to the trace. Starting with an unfiltered property export tends to produce a catalog of labels. Starting with a decision exposes why each field exists and what a failure would break.

Repeat until every active field has at least one named consumer or an explicit retirement decision. A field with no consumer may be clutter. A consumer with no documented inputs is an undocumented dependency.

Step 2: give each field a stable identity and one meaning#

A display label is not a stable identifier. HubSpot’s property editor documentation distinguishes a user-facing label from the internal name used by integrations and API calls. In HubSpot, the label may change, while the internal name and object type cannot be changed after creation.

Other CRMs differ, but the design lesson travels: record both the friendly label and the stable technical identifier. Never use the label alone as the integration contract.

Write the business definition as a testable affirmative statement. “Company size” is incomplete. State whether the field represents current employee count, a controlled employee band, a self-reported value at qualification, or an enriched estimate. Those are different facts with different owners, sources, types, and staleness rules.

Make null semantics explicit. A blank can mean not collected, not applicable, unavailable from the source, cleared after a conflict, or intentionally withheld. If all five collapse into one empty cell, no report can distinguish absence from failure.

For every controlled list, define the options by evidence rather than tone. “Qualified” should name the observable condition that permits the value. “Other” should say when it is allowed and where the unresolved detail goes. Free text is appropriate for narrative context; it is a poor substitute for a controlled fact used in routing or aggregation.

Step 3: separate field ownership from record assignment#

“Sales owns CRM data” is not an operating assignment. Microsoft recommends involving domain owners, data stewards, business experts, technical teams, producers, and consumers because no single role holds all the business and technical context.

Use a lightweight split:

Assign ownership to a durable role with a named current occupant and escalation path. “RevOps” can be a stewardship team; it is not sufficient if nobody in that team has authority to settle a disputed definition.

Step 4: name the source, writer, and precedence separately#

Source metadata answers several different questions that teams often compress into “source of truth”:

• Record origin: which process first created the record?
• Value writer: which user or process made this particular change?
• Authoritative source: which system or evidence is allowed to settle the field’s value?
• Source precedence: what happens when two permitted sources disagree?
• Verification evidence: what supports treating the current value as usable now?

HubSpot’s Record Source properties can identify the tool or process that created a record and provide details such as the form, import, user, workflow, or integration context. Its property history can show past values, change time, and change source.

That last distinction is critical. last_modified_at is not necessarily last_verified_at. A formatting workflow can touch a value without confirming that it still reflects reality. An import can be newer than a direct correction while carrying older source data.

For each field, write a precedence rule in plain language:

1. Name the primary authoritative source for the stated use.
2. List allowed secondary writers and the circumstances in which they may write.
3. State whether a verified manual correction is protected from a later automated overwrite.
4. Define the evidence and timestamp required to supersede the current value.
5. Route unresolved conflicts to a named steward instead of silently selecting the newest write.

Consider an illustrative deal.stage field. The contract might permit an authorized seller or approved stage workflow to write it, prohibit enrichment and marketing automation from doing so, require the entry evidence defined for each stage, and send an invalid transition to the opportunity steward. That is a source rule. “Use the latest value” is merely a timestamp rule and can preserve the wrong write.

Step 5: define staleness at the field-and-use level#

Staleness is not simply age. A value is stale when the contract no longer permits a named consumer to rely on it. Time can cause that state, but so can an invalidating event, a source conflict, a broken relationship, or a change in the rule itself.

Write six parts for each staleness rule:

Different field behaviors need different rules:

A useful implementation can express the rule as a boolean condition—age limit breached, invalidating event observed, or source authority lost—but that is a local control, not an industry formula. Record the approved limit and reason beside the rule. “Refresh every quarter” without naming the field, use, and consequence is a calendar reminder, not a staleness contract.

Step 6: turn the contract into controls and evidence#

Documentation changes behavior only when operating paths consume it. Implement the field contract in four layers:

The ODCS data-quality section shows how human-readable rules can become executable checks for null, missing, invalid, or duplicate values. HubSpot’s data-quality tools provide a product example: they surface duplicates, formatting issues, enrichment gaps, property use, fill rates, and anomalies.

Do not confuse a clean dashboard with a working contract. A field can be fully populated and consistently formatted while carrying the wrong meaning. It can be recently modified while based on old evidence. It can come from a known integration that was never authorized to overwrite it.

Test one field from capture to consequence#

Use a synthetic record in a safe test environment and trace one decision-critical field through every important state. The test should prove:

1. An approved source creates the field on the correct object with the expected source and verification metadata.
2. Invalid types, values, or required-state omissions fail visibly.
3. An unapproved user or integration cannot silently overwrite the value.
4. A permitted secondary source follows the documented precedence rule when it disagrees.
5. Property history or an equivalent log preserves the writer, time, and prior value.
6. The field becomes stale under the declared event or age condition without a meaningless write resetting its verification time.
7. Each downstream consumer applies the stated consequence rather than treating stale or conflicted data as current.
8. The steward can find the failure, repair or escalate it, and show evidence of the outcome.

Run the trace again after changing a field option, workflow, integration mapping, or consumer. Configuration screenshots prove what a setting looked like; traces prove what the system did.

Change the contract before changing the field#

A field change can break a workflow without deleting the field. Renaming an option, changing null semantics, replacing an authoritative source, shortening an allowed age, or moving responsibility can all alter downstream meaning.

For a material change:

• identify every known producer and consumer;
• state the old and new definition or behavior;
• classify whether the change is additive, compatible, or breaking;
• approve the migration, backfill, and exception treatment;
• test both direct and exported behavior;
• notify consumers before the switch; and
• retain the decision and effective date with the contract version.

Where a platform fixes internal identifiers after creation, as HubSpot does, a label edit does not repair a poor technical name. A replacement field may require dual writes, backfill, consumer migration, and controlled retirement. Treat the field as an interface, not a cosmetic setting.

Inventory every active field, then deepen the critical ones first#

You do need coverage for every active field, because an undocumented low-profile property can still overwrite a critical value or feed a forgotten export. You do not need equal ceremony for every field on the first pass.

Begin with fields that control identity, association, lifecycle or deal state, assignment, contactability, routing, financial interpretation, attribution, or automated action. Give those fields full definitions, source precedence, staleness rules, monitoring, and trace tests. For lower-consequence fields, establish the minimum row—meaning, owner, allowed source, freshness treatment, consumer, and change path—then deepen it when use or risk grows.

The practical standard is simple: no active CRM field without a shared meaning; no decision-bearing field without an accountable owner; no writable field without source authority and precedence; and no changeable field without a staleness rule and failure response. When those promises are written, configured, and traced, CRM data becomes dependable enough for a named decision—not “clean” in the abstract, but governed for actual work.