Building a customer golden record from ERP, CRM and e-shop with Boomi DataHub

A typical mid-sized company keeps customers in at least three places. The ERP creates the customer when the first invoice is issued, sales enter prospects and contacts in the CRM, and the e-shop registers anyone who places an order. Each system has its own ID, its own spelling of the name and its own idea of the current phone number. This article describes the pattern for bringing them together into one trusted customer record, then builds it step by step with Boomi DataHub.

Why point-to-point syncing falls short

The first attempt is usually a set of direct syncs: ERP to CRM, e-shop to ERP, CRM back to ERP. It works for a while, then:

• The number of flows grows quickly. Three systems need up to six one-way flows; a fourth system brings that to twelve.
• Nobody decides which value wins. If the CRM and the ERP both change the phone number, the last sync overwrites the other, and the “correct” value depends on timing.
• Duplicates multiply. The e-shop creates “Papadopoulos SA” while the ERP already has “Papadopoulos S.A.”. Each sync faithfully copies both.
• IDs get tangled. Every flow keeps its own mapping between ERP codes, CRM IDs and e-shop IDs, and they drift apart.

The pattern: a hub with contributing and accepting sources

In the hub-and-spoke (coexistence) pattern, every system sends its customer records to a central hub. The hub matches them, builds one golden record per real customer, remembers which source records belong to it, and sends agreed changes back to the systems that want them.

ERP ──┐                         ┌──► ERP (accepts: phone, email)
CRM ──┼──► hub: match + merge ──┼──► CRM (accepts: everything)
e-shop┘     golden record       └──► e-shop (accepts: nothing yet)

Two decisions per source define the design:

• Does it contribute? Its records are sent to the hub and take part in matching.
• Does it accept updates? It receives changes to golden records so its own copy stays consistent.

A source can do both, only one, or start as contribute-only until everyone trusts the hub. For our example:

Source	Contributes	Accepts updates	Notes
ERP	Yes	Yes (contacts)	Trusted for legal name and VAT number
CRM	Yes	Yes	Trusted for phone, contact person
E-shop	Yes	No (for now)	Many duplicates, contributes for matching only

Building it in Boomi DataHub

Boomi DataHub is organised in a few layers: a repository (where golden records are stored), models (the structure and rules of an entity, such as Customer), sources (the systems that exchange data with the repository) and the integration processes that move data in and out using the Boomi DataHub connector. Exact menu labels can change between releases, so treat the names below as a guide.

Step 1: Create a repository

In DataHub, create a repository on a hub cloud close to where your data must reside (for EU data, choose an EU location if available to you). The repository is where your domains, golden records and quarantine live.

Step 2: Design the Customer model

Create a model named Customer and add the fields you actually need to share. Resist copying every ERP column:

Field	Type	Example
name	Text	Papadopoulos S.A.
vat_number	Text	094123456
email	Text	info@papadopoulos.gr
phone	Text	+30 210 1234567
city	Text	Athens
postcode	Text	11526

In the model you also define match rules (how DataHub decides that two records are the same customer) and, optionally, data quality steps. Start with one simple exact rule, for example “same vat_number”. We cover richer rules in Match rules and duplicate handling in Boomi DataHub.

Step 3: Add the sources

Create a source for each system, with a short, stable code: ERP, CRM, ESHOP. Add the sources to the model and set, for each one, whether it contributes data and whether it accepts updates (channel updates), following the table above. Then publish the model and deploy it to the repository. The deployed model becomes a domain where golden records are created.

Step 4: Feed the hub from each system

For each contributing source, build a Boomi integration process:

1. Read changed customers from the system (ERP database or connector, CRM connector, e-shop REST API). Only read what changed since the last run.
2. Map the source record to the Customer model’s structure. The source’s own ID (for example ERP code C-1042) becomes the source entity ID, which is how DataHub links the golden record back to that system.
3. Send the records with the Boomi DataHub connector, using the operation that updates golden records for that source. DataHub then matches each record: it either links it to an existing golden record, creates a new one, or sends it to quarantine.

The payload the connector sends is a batch of entities tagged with the source code. Conceptually it looks like this (generate the real profile from the connector’s import, rather than writing it by hand):

<batch src="ERP">
  <customer>
    <id>C-1042</id>
    <name>Papadopoulos S.A.</name>
    <vat_number>094123456</vat_number>
    <email>info@papadopoulos.gr</email>
  </customer>
</batch>

For the first run, load each source in order of trust (ERP first, then CRM, then e-shop) so the strongest records form the base of the golden records. DataHub also offers an initial load mode for sources, worth checking in the current documentation before a large first import.

Step 5: Sync golden records back

For each source that accepts updates, build a second process:

1. Use the Boomi DataHub connector’s fetch channel updates operation for that source. It returns the golden record changes that the source has not yet received.
2. Map each update to the target system’s format and write it (for example, update the contact in the CRM).
3. If the update concerns a golden record that the source has never seen, create the record in the target and report the new ID back to DataHub, so the link is complete.

Schedule both kinds of processes, for example every 15 minutes, or trigger them from events if your systems can publish changes.

Step 6: Check the result

Open the domain in DataHub and search for C-1042. You should see one golden record with three linked source records (ERP, CRM, e-shop), each with its own ID, and a history of which source changed what and when. That link table is also a ready-made cross-reference for every other integration.

Before you go live

• Agree on ownership per field. Write down which source is trusted for each field before you configure anything.
• Start contribute-only. Let all sources contribute for a few weeks, review quarantine and matches, and only then turn on updates back to the sources.
• Watch the quarantine. Name a data steward and give them a daily slot to resolve entries.
• Prevent echo loops. When the CRM receives an update from the hub, its next “changed records” read will include that same change. Make sure it doesn’t create churn, for example by comparing values before sending.
• Handle errors properly. Feeding and syncing processes need retries and alerts like any other integration. See Error handling and retries in Boomi.

Summary

The golden record pattern replaces a web of syncs with one hub that decides “who is who” and which value wins. In Boomi DataHub the model holds the structure and the rules, the sources declare who contributes and who listens, and ordinary Boomi processes with the DataHub connector move data in and out. For the concepts behind it, read our Master data management: a practical guide.