Connect customer records around the work your team needs to do.

Choose one handover that is currently difficult. A wholesaler receives an enquiry about supplying a customer’s new branch. The CRM holds the relationship owner and the conversation. The ERP holds the customer number, delivery sites and orders. The person handling the enquiry needs to know whether this is an existing customer, which site is involved and who should respond.

Write the useful result in a sentence: the new enquiry reaches the relationship owner with the correct account and site references, relevant order history and any unresolved match. That sentence limits the first connection. It does not require copying every invoice, personal note or contact field into both systems.

If the immediate problem is a set of unreliable records, use the CRM data-quality checklist to inspect a sample first. This guide addresses the lasting rules behind the connection: identity, field responsibility, updates and exceptions.

A trading name can refer to a legal buyer, a group of companies or a location. A customer may have one invoice account and several delivery sites. Two sites can share an email domain while having different buyers, delivery conditions or account owners. Decide which of these distinctions changes the work before choosing a matching rule.

Keep a cross-reference between the stable IDs already held by each system. Treat the company name and domain as matching evidence, not as a guaranteed unique identity. Record an unresolved candidate match rather than assigning it to the first plausible company. Where the business has changed ownership or merged, preserve the old references needed to understand earlier transactions.

Platforms provide mechanisms for this, but they still need a business definition. Microsoft’s Dataverse documentation describes using a defined alternate key when an integration does not know the record’s primary key. That mechanism cannot determine whether two delivery sites should be treated as the same commercial account.

“The ERP is the source of truth” is too broad if the CRM contains the current relationship owner. Make a small table naming the field, responsible source, permitted readers and where a correction belongs. Different fields on the same account can have different responsibilities.

Separate a business change from a data correction. A new delivery address may be a new site; it may also be a misspelling in an old address. Changing the owner may reflect a territory reassignment, temporary absence or a corrected duplicate. Carry the reason and date when they matter to the next person.

For account C-218, the proposed rule is concrete: the CRM owner field may be read into an ERP service view, but an ERP import cannot replace that owner in the CRM. Confirmed delivery-site IDs and addresses travel from the ERP into the CRM. A salesperson finding an incorrect delivery address raises a correction for the ERP owner; editing the CRM copy alone does not repair the responsible record.

Do not give the newest timestamp automatic priority. An overnight import can be newer than a careful correction without being more accurate. Decide which changes can be accepted automatically, which require review and which should remain local to one system. Enrichment evaluation adds a separate check for externally supplied values.

Define a review queue for uncertain matches, missing owners and conflicting values. Show both values, their sources and dates, the affected workflow and the person who can decide. Explain what continues safely while the issue is open. For example, the enquiry can reach a reviewer while an automatic account update stays paused.

For S-02, the CRM postcode differs from a checked ERP correction. The operator verifies the site reference, refreshes the permitted address fields from the ERP and records the source revision. S-01 stays separate even though it shares the company name. If the ERP address is also disputed, the update waits for the person responsible for site data.

Duplicate detection and merging are different decisions. Microsoft’s duplicate-record guidance describes reviewing potential matches and selecting which field values survive a merge. Before using any platform’s merge operation, check its effect on activities, child records, permissions and the references held by other systems.

Never treat deletion in one system as an instruction to erase all related history elsewhere. Agree how retirement, changed access and retention decisions propagate. Restrict the connection to the records and fields its task permits, and make removal from that scope a test case.

Start with a confirmed account and site. Change the owner in the responsible source, submit the same event twice and interrupt the receiving connection after it may have saved an update. Check that the visible state distinguishes a confirmed save from an outcome still needing investigation.

Test a stale import after a newer approved correction. Test a site that shares a company name but belongs to another legal buyer. Test an authorised user losing access. An integration that passes only the first import has not demonstrated how it will handle ongoing work.

Record the expected result before each test, including which fields must remain unchanged. The workflow testing checklist provides a broader acceptance record; the commercial workflow specification assigns responsibility for the handover and recovery.

Take one recent enquiry and draw its account, site, owner and order references on a page. For each reference, write where it is held, how it is matched and who can correct it. Add one normal update and two exceptions. Ask the person receiving the result to explain what they would do with each version.

The unanswered questions define the next assignment. A separately agreed Plan can investigate identity and source ownership and hand the findings to your team. A standalone CRM-to-ERP connection has its own scope and quote. Within a Build campaign, agree which records and handovers support account selection, outreach and response handling, and which work your team or ClarityRev carries out. Use the useful parts of the existing setup and connect the information the task needs.