CRM and ERP integration: define data ownership before asking for a quote

Let's discuss your project →

What this guide helps you decide

If you need to connect a CRM with an ERP or management system, the real question is not whether the two products can be linked in theory. The useful question is: which process moves between the systems, who owns each field, and what happens when records conflict, duplicate, or fail to sync.

Microsoft’s integration guidance makes the same point from another angle: the design should follow the operational outcome, not the software brand. It separates UI integration, data integration, and process integration, and recommends choosing the pattern based on the business flow you actually need. Microsoft’s design guidance is a good starting point, but it does not replace the internal brief you need before asking for a proposal.

This article is for sales, administration, and IT leads who need a practical brief before speaking to a vendor. It gives you a complete simulated example, a data-ownership table, four test scenarios, a pilot plan, and the questions that turn a vague “can you integrate these systems?” into a request that can be priced and assessed.

What to prepare before the first vendor call

Before you ask for a quote, prepare four things:

  1. a list of the systems involved;
  2. a list of the fields to exchange;
  3. an ownership rule for each field;
  4. the failure and duplicate-handling rules.

That is the minimum. Without it, you will get estimates that sound precise but hide assumptions.

Microsoft’s product guidance also matters because available APIs and product capabilities can change the real scope. A Web API may exist, but that does not mean every object, rule, or workflow is exposed in the way your process needs. Microsoft’s product guidance is useful precisely because it reminds teams to verify the product, not infer it.

Audience

  • Sales teams that need customer data aligned across tools
  • Administration teams that manage master data and billing details
  • IT leads who have to decide scope, security, and implementation approach

Tools and prerequisites

You do not need a technical architecture document to start, but you do need:

  • access to the current CRM and ERP field lists;
  • someone who knows which department owns each field;
  • a short list of the most painful manual steps today;
  • one person who can approve the final scope.

What this article includes

  • one complete simulated case
  • one data-authority table
  • four test scenarios with expected results
  • a pilot checklist
  • a vendor question list
  • a reusable acceptance register

1. Define the business process before the technology

A CRM-to-ERP integration can solve several different problems, and each one leads to a different design:

  • reducing double entry;
  • keeping customer master data aligned;
  • reflecting commercial status in the management system;
  • pushing billing or invoice-related data from ERP back to CRM;
  • preventing duplicate customer records.

Microsoft’s guidance on integration design says to choose the pattern according to what the business needs to happen, including whether the flow is inbound, outbound, synchronous, or asynchronous. General integration guidance is useful here because it frames integration as a process decision, not only a software decision.

A practical rule is this:

  • if the CRM should merely display ERP-owned information, keep the flow one-way;
  • if the CRM is the place where sales changes are made, define exactly which fields it can update upstream;
  • if two systems can edit the same field, you need a conflict policy before any build starts.

2. Build the ownership table first

The most important page in your brief is the data-authority table. It tells the vendor what the integration is allowed to do and what it must never do.

Below is a complete simulated case. It uses a fictional customer, C-001, and two systems:

  • System A: CRM
  • System B: management system / ERP

Goal: keep a small set of customer fields aligned without allowing uncontrolled overwrites.

Simulated data set: customer C-001

CRM record
- customer ID: not present
- legal name: Alfa Ltd
- customer status: active
- billing address: 10 Roma Street, Florence

ERP record
- customer ID: IT-000184
- legal name: Alfa S.r.l.
- customer status: suspended
- billing address: 10 Roma Street, Florence

Data authority table

Field System of record Direction of flow Internal owner Conflict rule
Customer ID ERP ERP → CRM Administration never overwrite once assigned
Legal name ERP ERP → CRM Administration CRM may propose, ERP decides
Customer status CRM CRM → ERP Sales latest approved update wins
Billing address ERP ERP → CRM Administration CRM is read-only unless an exception is logged

This table is the heart of the project. It prevents a common mistake: trying to solve a governance problem with a technical connector.

Microsoft also documents that Dataverse exposes a Web API for operations on data and supports specific behaviors such as duplicate detection through headers. That is useful, but only after you have defined which fields are allowed to move and under what rules. Web API operations are a tool, not a design decision.

3. Write the scope in plain language

A good scope statement should read like an operational rule, not a sales promise.

Example of a useful scope statement:

Keep customer master data aligned between CRM and ERP for the fields listed in the authority table. The ERP remains the system of record for identity, legal name, and billing address. The CRM remains the system of record for commercial status. Duplicate records must be flagged for human review. Errors must be queued or retried according to the agreed operational rule.

That one paragraph already answers several questions a vendor will ask later:

  • What is in scope?
  • Who owns what?
  • What happens on failure?
  • What must be reviewed by a person?

4. Test the integration with four simulated cases

The following four scenarios are editorial simulations. They are not claims that a test was already executed.

Case 1: initial creation

Input: ERP sends a new customer record to CRM with ID IT-000184, legal name, and billing address.

Expected result:

  • CRM creates the customer record;
  • the customer ID is stored as-is;
  • fields excluded from the scope remain untouched;
  • the log records source, timestamp, and record ID.

What to check: the CRM does not generate a second ID, and the record matches the ERP version for ERP-owned fields.

Case 2: concurrent change

Input: sales changes customer status in CRM from active to to call back, while administration corrects the legal name in ERP.

Expected result:

  • the CRM change is accepted because customer status is CRM-owned;
  • the ERP change is propagated back to CRM for the legal name;
  • neither system silently overwrites the other’s authority;
  • the audit log shows both changes and the field ownership rule used to resolve them.

What to check: the integration does not treat the whole customer record as a single block when only one field changed.

Case 3: duplicate record

Input: a new customer with a similar legal name arrives without a trusted external ID.

Expected result:

  • the integration does not create a second active customer automatically;
  • the record is placed in a review queue;
  • an operator decides whether to link, merge, or reject it;
  • the duplicate rule is logged.

Microsoft’s Dataverse documentation mentions duplicate detection behavior in the API layer, but the exact outcome still depends on the system configuration you use. That is why the pilot must verify the behavior in your own environment, not only on paper.

Case 4: system unavailable

Input: the ERP does not respond during the nightly synchronization window.

Expected result:

  • the record is not lost;
  • the event is retried or queued according to the rule you agreed;
  • the operations team receives an alert;
  • replay uses an idempotent identifier so the same update is not applied twice.

What to check: failure handling is visible and recoverable, not hidden in a log no one reads.

5. Decide what the pilot should prove

A pilot is not a small version of production. It is a controlled way to answer specific questions.

For a CRM-ERP integration, the pilot should prove at least five things:

  1. the right fields move in the right direction;
  2. field ownership is respected;
  3. duplicates are not created automatically;
  4. failures are recoverable;
  5. the audit trail is understandable to non-developers.

A practical pilot plan

Step 1: narrow the scope

Start with customer identity, legal name, status, and billing address only. Do not expand to contacts, orders, invoices, and service cases at the same time.

Step 2: define the test set

Use a small number of known records, including one clean record, one conflicting record, one duplicate-like record, and one record that will fail because the ERP is temporarily unavailable.

Step 3: agree on the acceptance criteria

The pilot is successful if the system behaves according to the authority table and the error rules. It is not successful if the data moved but the ownership rule was violated.

Step 4: review the operational load

Measure how many manual interventions are needed and who performs them. If the integration simply moves work from one inbox to another, the project has not solved the underlying process problem.

6. Questions to ask the vendor

Use these questions in the first commercial conversation:

  1. Which system is the source of truth for each field?
  2. Is the integration one-way or bidirectional?
  3. How are duplicates detected and reviewed?
  4. What happens when one system is temporarily unavailable?
  5. Which objects are actually exposed by the product’s API?
  6. What permissions are required, and can they be limited by role?
  7. How are retries, idempotency, and reprocessing handled?
  8. Which data is excluded from the standard scope?
  9. What monitoring and audit logs will we receive?
  10. What part of the process will remain manual after go-live?

The value of these questions is not the list itself. It is the way they separate design assumptions from verified product behavior.

7. Do not send sensitive data by email

For the initial discussion, send only what is necessary:

  • field lists;
  • process description;
  • sample data masked or synthetic;
  • known exceptions;
  • volumes in broad terms;
  • internal owners.

Do not send:

  • credentials;
  • API tokens;
  • full exports with personal data;
  • admin screenshots with sensitive details;
  • confidential documents that are not needed for scoping.

If real test data is required later, it should be transferred only into an approved test environment, through an agreed secure process.

8. Acceptance register you can reuse

Here is a simple register you can copy into a project brief.

Check Owner When Acceptance rule
Customer ID is not regenerated Administration end of pilot no duplicate identities
CRM-only status changes are preserved Sales during pilot no unauthorized overwrite
ERP-owned fields remain ERP-owned Administration during pilot authority table respected
Duplicate candidates go to review Administration + IT during pilot no automatic merge
Failed updates can be retried safely IT failure test no double write
Log is readable and complete IT + business owner end of pilot source, time, and reason recorded

9. What changes when APIs and product limits are involved

This is where many proposals become too optimistic. An integration can be technically possible and still not fit the process.

Typical scope changes include:

  • the API exposes some objects but not the exact business entity you need;
  • rate limits or throttling affect synchronization frequency;
  • product licensing changes what is available in practice;
  • environment and implementation choices change what can be supported safely.

Microsoft’s guidance is relevant here because availability and product behavior can shape the project perimeter. In other words, even before implementation, you may need to decide whether the proposed design is compatible with the product boundaries and the way the service is delivered.

10. Where this fits in Dedaloop’s offer

If you need this kind of project framed as a software initiative, the most relevant service page is Custom software and integrations. If you already know the process and want to discuss it with a team, use Contact Dedaloop.

Two related reads may also help:

Those pages sit naturally next to this article because the problem is not just coding. It is scope, ownership, security, and acceptability.

Final checklist before asking for a quote

You are ready to ask for a proposal when you can answer these questions in writing:

  • What business problem are we solving?
  • Which systems are involved?
  • Which fields move between them?
  • Who owns each field?
  • What happens on conflict?
  • What happens on duplicate detection?
  • What happens on failure?
  • What must remain manual?
  • Which data is excluded?
  • How will we decide the pilot succeeded?

If you cannot answer those questions yet, the next step is not to request a quote. It is to finish the brief.

That is the practical difference between a vague integration request and a project a vendor can actually estimate, build, and validate.

Sources