Skip to content

Connect CRM and ERP: define the data source for each field

A completed field table defines sources and write directions. It separates contact maintenance, billing address and account state across CRM and ERP.

Tobias Krüger2 min read
Green address field with a location pin and a tab bearing a gear symbol.

Before connecting CRM and ERP, define where individual values are changed and confirmed. A customer can exist in both systems while different fields have different owners. This produces a data contract for implementation: identity, field meaning, authoritative source and permitted write direction.

Identify the same record unambiguously

A fictional software company links CRM customer C-204 to ERP customer account D-630. The mapping should remain stable through these references; a similar company name is insufficient. For Dataverse, Microsoft describes alternate keys that can identify rows through unique column values, for example. Which keys the actual systems provide belongs in the technical assessment.

In the following example, “authoritative” means that this system confirms the valid field value. The other system may display it or submit a change request. Field names and values in the table are a custom design for this example, not a provider’s API fields.

Fill in the source and direction for each field

Field

Example value

Authoritative source and direction

Change in the other system

Project contact technicalContactEmail

projekt@example.invalid

CRM → ERP, as a technical contact.

Display only in ERP.

Billing address billingAddress

Werkstraße 8, Beispielstadt

ERP → CRM.

Capture a change request in CRM.

Account state billingAccountState

active

ERP → CRM.

A sales status in CRM does not change this value.

Direction is defined per field; a blanket rule that CRM is authoritative would not represent this division. Microsoft’s dual-write documentation shows one-way and two-way column mappings; the specific data contract determines which direction fits this case.

Treat a different entry as a change request

If sales submits the new address Werkstraße 12, Beispielstadt in CRM, an open request should be created first. The authorised ERP team reviews it and confirms the change if appropriate. Only the confirmed ERP value flows back. Requested and confirmed addresses therefore need distinct states.

If transfer fails, CRM needs to keep the open request and last confirmed version distinguishable. Sending work to the interface is not confirmation from the target system. Processing time and outcome should be traceable against the case.

Check three transfers against expected results

Check the agreement in an appropriate test environment before use:

  • A contact address changed to projekt-neu@example.invalid in CRM appears as the technical contact in ERP.

  • An address request initially leaves the confirmed value Werkstraße 8, Beispielstadt unchanged. After ERP approval, the new address appears in CRM too.

  • If ERP changes the account state to blocked, CRM shows that state. Changing the sales status does not remove the block.

These results check different fields and write permissions. Successfully transferring a single record does not fully cover all three rules.

Sources

Written by

  • Tobias KrügerEditor for Systems IntegrationTobias Krüger covers how different software systems work together at ASES. In his articles he explains how ERP, CRM and online shops are connected and how to deal with errors in data exchange.

Follow ASES

Read more

All articles
Insights · APIs & Integration2 minTwo-way synchronisation needs explicit write rulesIf CRM and ERP can write, each shared field needs a conflict rule. The last message to arrive is not automatically the latest business decision.Tobias KrügerNov 13, 2026
Glossary · APIs & IntegrationSystem integrationSystem integration links applications, data and work steps. Interfaces alone are insufficient: identifiers, field meanings and outcomes need to agree.Nov 13, 2026
Glossary · APIs & IntegrationData mappingData mapping defines how source data enters a target structure. Field names, meaning, units and error handling all need to fit.Nov 13, 2026
Glossary · APIs & IntegrationMaster dataMaster data describes core business entities such as customers or products. It is reused across processes and can still change over time.Nov 13, 2026
Insights · APIs & Integration2 minClarify an interface’s job before replacing itAn outdated connection may still carry important workflows. Its replacement needs clarity about effects, exceptions and open operations.Tobias KrügerNov 13, 2026
Insights · APIs & Integration2 minIntegrations need accountable owners after launchAn operating connection needs decisions about changes and incidents. Technical setup alone does not assign that responsibility.Daniel HartmannNov 13, 2026
Insights · APIs & Integration2 minIntegration effort depends on the data path you needTwo tools with APIs can require different preparation. The deciding factors are the required data, operations and permissions.Tobias KrügerNov 13, 2026
Insights · APIs & Integration2 minA shared data model needs agreed meaningThe same field can mean different things in a CRM and an ERP. The teams need to agree its meaning before defining a shared structure.Tobias KrügerNov 13, 2026

APIs & Integration with ASES

ERP, CRM and shop cleanly connected

Request a quoteMore on APIs & Integration