Choose a CRM Source of Truth for Each Shared Field

Choose authority for a specific field and business event, then restrict the other writers. Calling the CRM the source of truth for everything leaves important questions unanswered: who can correct an invoicing address, whether a blank should erase a value, and what happens when an old event arrives after a correction. A useful ownership rule answers those questions before the sync runs.

For a consultancy, the deliverable is a field authority register backed by conflict tests. It sits beside the CRM data-mapping specification. The map explains how a value moves; the register decides whether that movement is permitted at this point in the process.

Separate the meaning before choosing the owner

Consider a fictional client that uses a CRM, a billing application, and an onboarding form. Each has an address. Sales wants a mailing address, finance needs the approved invoice address, and operations needs a delivery location. These may coincide, but they represent different facts. Making one address overwrite the other two would hide the distinction rather than resolve it.

Write a plain definition for every shared field. Record what the value represents, which business action uses it, and who can approve a correction. If stakeholders describe different meanings, split the fields or agree a canonical definition before discussing sync direction. A connector cannot settle a disagreement over what a field means.

Distinguish a request from an accepted value. A customer may propose a new billing address through a form, while finance remains responsible for accepting the change. Store the proposal separately if the process requires review. A form submission is evidence of a request, not automatic authority to alter every downstream system.

Build a register that can drive implementation

Use one row per field and authority condition. The following fictional examples illustrate decisions a client might approve; they are not platform defaults.

Field and condition	Authoritative event or system	Permitted action elsewhere	Conflict route
Invoice address after account activation	Finance-approved billing update	CRM displays the accepted address	Finance reviews a proposed correction
Opportunity stage while selling	Authorized CRM stage transition	Billing may read the stage	Sales operations reviews inconsistent transitions
Delivery location before onboarding approval	Reviewed onboarding submission	CRM holds a proposed value	Operations resolves conflicting submissions
Calculated invoice balance	Billing calculation	CRM displays a dated copy	Finance investigates a reconciliation difference

For implementation, extend each row with the source and destination property identifiers, relevant record ID, authorized writers, missing-value behavior, rule version, and business owner. Include a link to the decision that established authority. Keep sensitive record contents in the approved systems rather than copying them into the register.

Avoid a row that simply says “latest update wins.” If that is the chosen policy, specify which timestamp represents the business change, whether clocks and event ordering can be trusted, and how ties or missing timestamps are handled. Arrival time at the connector may describe network delay rather than a new business fact.

Define what each writer is allowed to do

An integration account, user, import, and native workflow may all write the same property. Inventory them before changing the main connector. Disabling one path will not protect the field if a nightly import still replaces it.

Give each writer an explicit role: propose, accept, mirror, or reject. A mirror copies an already accepted value. It should not become an independent decision source merely because the mirrored record was saved recently. Derived fields need a named calculation owner; editing the displayed copy is usually a different operation from correcting the source inputs.

Where the platform permits access restrictions, test them with the intended account. Where it does not, document the limitation and choose an operable control with the client, such as a separate proposed-value property or a controlled review process. Do not describe a written rule as enforced until the actual write paths have been exercised.

Decide blank, correction, and deletion behavior separately

A missing property in an event, an empty string, an explicit clear request, and a deleted source record are different inputs. Give each one a defined treatment. For example, an omitted invoice address might leave the accepted value intact, while a finance-approved clear request creates an exception because billing cannot proceed without an address.

Corrections deserve their own path. If an operator discovers a wrong authoritative value, they need to correct the source or request an approved exception. Repeatedly fixing the mirror creates a contest the next sync may reverse. Record temporary overrides with an owner and a condition for removing them. An override with no end condition becomes an undocumented second authority.

Do not assume deleting a source record should delete its destination counterpart. The destination may participate in other relationships or processes. Make deletion, archiving, and relationship removal separate decisions with their own evidence and approval.

Make ownership transfers explicit

Authority can change at a business milestone. In the fictional address example, an onboarding proposal becomes accepted after operations approval. Specify the exact transition event, required approval evidence, and treatment of records already in transit when the transition occurs.

A safe design might check the current lifecycle state before applying a proposed update. Whether that check is available, and whether it prevents concurrent writes reliably, must be verified in the actual system. If a connector cannot establish the current state safely, route the uncertain case to review instead of inventing an ordering guarantee.

Plan the initial population separately from ongoing updates. A migration may seed a field from a legacy export, while later changes come only from the new application. Mark the cutover boundary so an old import cannot regain authority simply by being rerun.

Test a conflict, not just a successful copy

Use a small synthetic dataset and inspect both systems after each case. Save the expected accepted value before execution. These cases expose different failures:

1. An authorized change updates the destination and records its origin.
2. An unauthorized change proposes a correction without replacing the accepted value.
3. An older event arrives after a newer accepted correction.
4. An event omits the field, followed by an explicit request to clear it.
5. A mirrored change returns through another sync path and must not create an endless reversal.
6. Authority transfers while an earlier event is waiting for processing.
7. An operator corrects the source, then a scheduled import runs.

For each test, retain the record identifiers, rule version, event reference, observed values, and relevant side effects. Where change history is unavailable, say what cannot be proven and agree another verification method. A successful connector response alone does not prove the accepted field remained correct after other writers ran.

Give operators a resolution procedure

A conflict entry should show the field, competing origins, applicable rule, and reviewer. The reviewer should be able to inspect the authoritative record, choose the accepted correction through the approved path, and confirm that connected copies converge. Avoid retrying every failed item together when some require business decisions.

Before release, ask the client to resolve one synthetic disagreement using only the register and operator notes. If they cannot identify who may accept the value, ownership is still incomplete. If they can decide but cannot apply the correction safely, the implementation needs another control or a narrower scope.

Review the register when a new import, form, integration, or lifecycle policy is introduced. Use workflow change control to connect the revised authority rule to affected tests and release evidence. For a bounded demonstration of the proposed behavior, request a sample-data workflow design. The useful outcome is a rule the client can explain, enforce, and repair when connected systems disagree.