Data governance
Establish a shared meaning for customer data, ownership and responsible use.
On this page
Keep a field ownership register
Document the business meaning, source system, allowed values, steward and retention expectations for critical fields. Customer identifiers, lifecycle stages, campaign taxonomy and consent need consistent definitions across operations and reporting.
Represent consent explicitly
Permission to process a transaction is not the same as permission to send marketing. Preserve the scope, source and time of consent where required. Define how changes are propagated and which workflows must stop when a permission changes. Legal requirements must be reviewed for the relevant jurisdiction and use case.
Design access around responsibilities
Separate service identities from personal accounts. Grant only the permissions needed for each process and document the owner of credentials. Review access during staff changes, vendor changes and periodic operational reviews.
Measure quality in context
Check completeness, allowed values, duplicates and relationships before acting on data. Quality thresholds should reflect the decision they support. An incomplete company size may be tolerable for one report and a blocker for a routing rule.
Make change visible
Version important schemas and taxonomy decisions. Record the impact of field changes before deployment and coordinate source owners, integration maintainers and report owners. Keep a clear path from a reported metric back to its definition and source.
Write a practical field contract
A field dictionary becomes operational when it names who may change each value and what an absent value means. Distinguish an omitted field, a deliberately cleared value and a value that is unknown. For shared customer data, define these rules before enabling updates in both directions. Assign ownership by business meaning: CRM manages relationship state, preference records manage communication permission and finance governs recognized revenue.
| Field | Authority | Contract rule |
|---|---|---|
| Account owner | Sales operations | External systems may propose reassignment, but do not overwrite the approved owner. |
| Communication permission | Preference process | Preserve purpose, channel, source and effective time. |
| Campaign code | Marketing operations | Use a controlled taxonomy and retain retired codes in history. |
| Recognized revenue | Finance system | CRM opportunity value is not a substitute for the finance definition. |
Make quality checks decision specific
A record can be suitable for aggregate reporting and unsuitable for automated routing. Define the checks at the point where the data is used. For example, routing may require a verified account and an eligible owner, while a campaign report can retain unmatched activity in a separate category. Keep the failed rule, record reference and responsible steward so a quality score leads to a correction process.
{
"policy": "lead_routing_v1",
"required": ["source_record_id", "account_reference", "region"],
"allowed_write_fields": ["routing_reason", "proposed_owner"],
"on_missing_identity": "review",
"on_unknown_region": "fallback_queue",
"on_permission_denied": "stop"
}Trace a schema change through its consumers
Before changing an allowed value, field type or relationship, list the workflows, exports, reports and teams that consume it. Test the new version against representative historical records, including empty and retired values. Decide whether to backfill, translate at the boundary or retain both versions during migration. The release record should name the owners who confirmed compatibility and the evidence used to close the change.
Standards and documentation
Explore the protocol specifications and platform guidance for this topic.
Bring the contract into your operating environment.
Discuss an implementation