When your CRM and ERP disagree, which fact should AI use?

Your assistant should return an address with its purpose, governing record and approval status—or an exception for a named reviewer. That is the proposed workflow: not “pick the most plausible address,” but “apply the authority rule for this order.”

Our position is simple: share the meaning; preserve the ownership. A company ontology should define customers, orders and addresses without quietly becoming their replacement system of record. This follows the separation between semantic definitions, operational facts and request-time context described in Global Advisors’ implementation report.

What the implementation evidence establishes

In its September 13, 2026 case study, Global Advisors reports an ontology and context architecture in active internal use, while source coverage and selected integrations continue to mature. Operational systems retain fact ownership; unresolved identities remain separate without an authoritative assertion or reviewed crosswalk. Ambiguous matches can trigger abstention rather than a silent merge. These are self-reported implementation details, not independently verified business results. Source

The strongest qualification is architectural: its normal request path uses a compiled, immutable read model without source-system calls. That is useful context architecture, but should not be treated as proof of current dispatch instructions. Our proposed pilot therefore separates answering from authorising action and requires fresh authoritative checks before consequential steps. Reported architecture

1. Define the address before choosing its source

We would start with a redacted customer record pair and the delivery decision it affects. Map the customer identifiers across systems, link the order and its lines, and distinguish account correspondence, default delivery and order-specific delivery addresses. Record each mapping’s owner and approval basis; leave uncertain identity matches unresolved.

This distinction has a concrete product analogue. Microsoft documents customer selection of an order’s shipping address separately from saving a primary address. It also supports line-specific shipping addresses when the relevant configuration is enabled. “The customer address” is therefore too loose a definition for this pilot. Microsoft shipping-address documentation

For each mapped address, we would capture purpose, source record, applicable order state, effective period, approval evidence and an agreed freshness limit. These are proposed pilot requirements, not reported functionality from the case study.

2. Agree the authority table

The following is a proposed decision table to approve with your operations team—not a universal rule that ERP outranks CRM. Each row assumes identity is confirmed and the relevant source can be checked.

Situation	What the assistant may present	Human checkpoint
CRM correspondence address differs from an approved ERP order-line delivery address; your policy assigns that order state to ERP	The order-line address, labelled for that order; show the different correspondence address separately	No change proposed; normal dispatch approval remains
CRM contains a later delivery-address update whose applicability to the open order is unapproved	Both records, labelled as an unresolved delivery conflict; no selected dispatch address	Authorised order owner confirms applicability and effective period
No order-specific address exists	A default only as a candidate, from the source designated by your policy	Authorised order owner approves before it becomes an order instruction
Customer mapping, approval evidence or authoritative freshness check fails	No usable dispatch selection; return the failed check and relevant references	Named exception reviewer resolves the missing evidence

Under this proposal, a later timestamp is evidence of an edit, not permission to redirect a shipment. Different address purposes need not constitute a conflict; competing instructions for the same delivery do.

3. Make resolution explicit—and keep writes separate

We would give the reviewer the competing records, affected order lines, applicable authority rule and reason for abstention. The reviewer should be able to retain the existing instruction, approve a change through the responsible system, or request clarification. Record the decision, approver and effective scope.

Keep address changes and customer commitments under human approval. Before any approved downstream action, recheck the authoritative record and stop if freshness or approval checks fail.

Test propagation rather than assuming a change stays local. Microsoft documents that, for its direct-delivery workflow, changing the delivery address on either the purchase-order line or originating sales-order line automatically updates the corresponding line. That specific behaviour makes downstream integration testing part of this pilot’s scope. Microsoft direct-delivery documentation

4. Measure the decision, not the draft

We would first run the workflow read-only against reviewed record pairs. Measure elapsed time from conflict identification to authorised resolution, incorrect address selections against reviewer-approved decisions, and unresolved cases. Compare the same measures with your existing process; agree acceptance criteria before enabling writes.

Do not budget against assumed savings. The supplied implementation account establishes architecture, not independently verified address-error reduction or conflict-resolution timing. Those outcomes remain to be measured in your workflow. Implementation evidence

The trade-off we recommend is deliberate: accept an explicit review queue rather than silently resolving uncertain delivery instructions. Start with one conflicting record pair, approve its authority rule, and test whether the assistant selects correctly—or abstains for the right reason.