Encode the field policy beside the mapping

Define one field completely

Choose a field such as operational account status and state which system owns it. Describe the destination property, accepted values and how unsupported values are handled.

Keep display labels separate from provider property identifiers. A label renamed by an administrator should not silently change the integration's meaning.

Write examples for a normal update, an omitted value and an explicit clear before implementing the transport call.

{
  "field": "operationalAccountStatus",
  "authority": "operations-service",
  "destinationProperty": "operations_status",
  "onMissing": "leaveUnchanged",
  "onExplicitClear": "reject",
  "onDestinationEdit": "reviewConflict"
}

This is an illustrative application policy. The destination API's actual encoding and supported values must be verified separately.

Apply only the intended properties

Construct a patch from fields the source is authorised to change. Avoid serialising an entire stale local contact object into every update.

Preserve the source record revision or change identity where useful for ordering and duplicate handling. A delayed event should not overwrite a newer authoritative value without an explicit policy.

For platforms supporting conditional updates, use the documented precondition mechanism where it fits the workflow. Dataverse exposes conditional operations through its Web API, but support and semantics must be checked for the actual table and operation.

Save the mapping and outcome

Record the local and provider record identities, applied field set and operation result. Keep sensitive values out of broad logs while retaining a controlled investigation path.

If the external write succeeds but local persistence fails, preserve an uncertain state and reconcile rather than sending an unrelated full update.

Classify rejected values separately from transient transport errors so an invalid mapping does not retry forever.

Test all writers against the policy

Run a live update, batch import and support repair through the same field rules. Confirm that each preserves CRM-owned fields and handles clearing consistently.

Then edit the destination during the update and verify the documented conflict behaviour. The policy is useful only if every integration path follows it, including the tools used during an incident.