> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # CRM field ownership and write authority > How ownership and precedence policies prevent correct-looking automations from creating conflicting CRM truth. CRM governance defines who can change an operating fact and why that change is acceptable. It connects the team's business policy to the automations and people that act on a record. A field containing text is not necessarily a trusted field. ## Different fields have different consequences A company domain supports identity. A contact owner controls routing. A deal stage affects forecasting. Those fields should not inherit the same write rule simply because one integration can technically update all of them. Consider an enrichment Play that finds a new job title. The title may be valid source evidence, while reassignment of the account still depends on territory and ownership policy. An enrichment capability does not authorize every commercial consequence that could follow from its output. ## Competing writers create competing interpretations A CRM workflow, an enrichment integration, and a rep might all update the same property. Each can behave correctly under its own rule while the combined system alternates between values. A field-ownership policy identifies the authoritative source or writer and what other processes may propose. Precedence explains how disagreements are resolved. These are business policies that workflow code must implement; Deepline does not infer them from the property name. Exclusive ownership is one possible design, not an automatic database lock. Where several writers remain necessary, the team needs a destination-supported concurrency policy or explicit reconciliation. ## Observation, proposal, and accepted change are distinct A provider observation says what a source reported. A proposal says what a workflow recommends changing. An accepted change says that the evidence and write policy permit the update. Keeping these separate prevents a plausible candidate from becoming an operating fact too early. For example, a new employee-count estimate can remain a proposed field while the current CRM value stays available. A reviewer can then see the observation time, identity match, and reason the workflow prefers the candidate. [Provenance](https://deepline.com/docs/guides/data-provenance-in-crm.md) supplies that evidence history. Governance supplies the authority to act on it. One cannot replace the other. ## Read-back establishes a narrower fact than approval A successful write response can be useful evidence, but the workflow may also need to verify the destination's observed state. That verification can expose partial changes or mapping problems. Reading before and after does not by itself make the operation atomic. Another writer can change the property between those reads. The verified value is also an observation at a time, not a promise that it will remain unchanged forever. ## Exceptions belong to the operating model An ambiguous match or uncertain write is not necessarily a reason to discard the record. It is a reason to preserve the evidence and identify the policy or operation that needs attention. A review queue is a workflow the team implements, not a universal automatic feature of every Play. Its useful purpose is to keep uncertainty visible while protecting operating fields from unsupported updates. ## Apply this understanding * [Repair CRM data](https://deepline.com/docs/guides/crm-data-quality-automation.md): field policies, proposals, and verification. * [HubSpot enrichment](https://deepline.com/docs/guides/hubspot-enrichment-workflows.md): identity resolution and property mapping. * [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md): destination ownership and retries. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.