A Deterministic Precedence and Merge Strategy for Conflicting Customer Data Across Systems

Why customer records conflict in the first place

When an AI agent can read and write across CRM, ERP, billing, and ITSM, the same “customer” stops being a single row in a database and becomes a set of partial truths. Sales might update a company name in the CRM, finance might correct the legal entity in ERP, billing might hold the authoritative tax profile, and ITSM might track a requester as a person with a different email and spelling. If the agent writes back naively, it can overwrite a correct value with a convenient one—and the organization ends up with broken invoices, misrouted tickets, or failed renewals.

The fix is not “use a master system” as a slogan. You need a deterministic precedence and merge strategy: a set of rules that always produces the same result from the same inputs, explains itself, and can be audited. That strategy should be explicit enough for humans to review, but also machine-executable so agents can apply it consistently in real workflows.

The goals of a deterministic merge strategy

1) Safety for writes

Agents should only write values that are high-confidence and policy-compliant. A deterministic approach lets you restrict writes to fields where the merge outcome is unambiguous or requires approval when it is not.

2) Stable identity and attribution

Conflicts are often identity problems disguised as field disagreements. If you merge customer identities incorrectly, every downstream field becomes suspect. A reliable strategy starts with persistent entity IDs and clear identity resolution so updates land on the right record.

3) Explainability and audit

When finance asks “why did the address change?” you need a replayable decision: which sources were considered, which rule fired, what evidence existed, and when.

Start with a canonical customer model

Before precedence rules, define the “shape” of customer data you want agents to reason about. This is not a new database; it’s a canonical model used for decisioning and orchestration.

• Entities: Account (company/legal entity), Contact (person), Subscription/Contract, Payment Method, Ticket/Case.
• Identifiers: stable internal IDs plus source-specific IDs (CRM account ID, ERP customer number, billing customer ID, ITSM requester ID).
• Field classes: identity fields (name/email), legal/compliance fields (VAT, billing address), operational fields (shipping address), and engagement fields (lifecycle stage, last touch).

This makes it possible to say “Billing address is a compliance field” and treat it differently than “support contact phone number.”

Precedence is per field, not per system

A common failure mode is setting one system as “source of truth” globally. In practice, truth is field-specific.

Define an explicit precedence table

Create a table that maps each canonical field to a ranked list of sources and conditions. Example patterns:

• Legal name: ERP > Billing > CRM (unless ERP is blank or older than X days).
• Primary billing address: Billing > ERP > CRM (and never accept a “free-text” address without normalization).
• Support contact email: ITSM > CRM (but only if verified and not a role inbox blacklist).
• Lifecycle stage: CRM > (others ignored).

Crucially, each rule should declare why that system is preferred for that field (compliance, operational ownership, verification level), so it survives tool changes over time.

Make merges deterministic with a scoring and tie-break framework

Precedence alone is not enough when sources disagree and none is clearly correct. Determinism comes from applying the same scoring, tie-breaks, and fallbacks every time.

Step 1: Normalize before comparing

Normalize values into comparable forms:

• Emails: lowercase, trim, punycode domains when needed.
• Phone numbers: E.164 formatting and country inference rules.
• Addresses: parse into components, standardize abbreviations, validate postal codes.
• Company names: strip suffix noise (Inc, GmbH) while preserving legal variants for legal fields.

This reduces “false conflicts” created by formatting differences. If you’re handling brand or entity naming consistency, a companion approach is to maintain alias sets and canonical forms so the agent doesn’t split one company into multiple identities; see Entity Alias Canonicalization for LLMs to Prevent Split Brand Understanding.

Step 2: Score each candidate value

For each field, compute a score for each source’s candidate value. A practical scoring model uses:

• Source rank (from your precedence table).
• Freshness (timestamp, last verified date).
• Verification level (e.g., “invoice-issued address” beats “typed in chat”).
• Completeness (full address beats partial).
• Consistency checks (VAT matches country, postal code valid, email domain aligns with account).

The merge outcome is simply the highest scoring candidate. If scores tie, you apply deterministic tie-breaks (e.g., prefer the value that matches an existing stable identifier, then prefer the system with stricter validation, then fall back to “no change”).

Step 3: Use “no write” as a first-class outcome

Many strategies fail because they force a winner. Deterministic does not mean “always overwrite.” Define explicit “blocked” outcomes:

• Conflicting legal fields without a high-confidence winner → require approval.
• Identity fields that would merge two accounts → create a review task.
• Address changes on active subscriptions → update pending confirmation.

Identity resolution rules that prevent silent corruption

Before field merges, define deterministic identity matching rules. Use a layered approach:

• Hard match: shared persistent internal entity ID or explicit cross-system mapping table.
• Strong match: billing customer ID + domain match; or ERP customer number + tax ID match.
• Soft match: name similarity + address similarity + email domain, with conservative thresholds.

When the agent cannot confidently match, it should avoid writes and instead create a linking task. This is also where persistent entity IDs dramatically reduce attribution breakage when data moves across tools; the same idea is explored in Why AI Citations Break When Attribution Leaks and How Persistent Entity IDs Fix It.

Write policies for AI agents operating across CRM, ERP, billing, and ITSM

A deterministic merge strategy becomes operational when paired with clear write policies:

• Field-level permissions: an agent can update CRM “industry” but not ERP “payment terms.”
• Change windows: allow billing address updates only before invoice creation or via a controlled workflow.
• Evidence requirement: require a document, invoice, or verified user confirmation for legal fields.
• Approval routing: finance approves tax and payment fields; support leads approve contact merges.

This is where an AI-native orchestration layer is useful: it can apply the same merge and policy logic across channels and tools, then decide whether to write, ask, or escalate. Platforms such as typewise.app are designed to sit above existing systems, orchestrate specialist agents, and keep humans in control through approvals and handoffs—making deterministic merge rules enforceable rather than just documented.

Operationalizing the strategy with logging and replay

To keep precedence rules trustworthy over time, treat merges like a governed decision pipeline:

• Decision logs: store the candidates, scores, winning rule, and reason.
• Diff-based writes: only write fields that changed and passed policy gates.
• Simulation before rollout: run merges on historical conflicts to estimate impact and catch regressions.
• Exception queues: collect “no write” outcomes into a review workflow so humans resolve the hard cases once.

Determinism is what makes this governable: you can replay the same inputs and validate you get the same outputs, which is essential for debugging agent behavior and proving compliance.

A practical template you can implement this quarter

• Define canonical entities and field classes.
• Create a field-level precedence table with ownership rationale.
• Normalize values before comparison.
• Score candidates with deterministic tie-breaks.
• Allow “no write” outcomes and route to approvals.
• Log, diff, and replay merge decisions.

Once this is in place, AI agents can safely operate across CRM, ERP, billing, and ITSM without turning every workflow into a data integrity gamble.