A canonical data model in Boomi

The first order integration maps the e-shop straight to the ERP. Then a marketplace arrives and gets its own mapping to the ERP. Then the warehouse system needs orders too, so there are mappings from the e-shop and the marketplace to the WMS. Then the ERP is replaced, and every one of those mappings has to be rewritten. This article explains the canonical data model, the pattern that keeps this under control, and builds it in Boomi.

Why direct mappings don’t scale

With direct mappings, every pair of systems that exchanges orders has its own translation:

e-shop ──────► ERP          3 sources × 2 targets = 6 mappings
marketplace ─► ERP
B2B portal ──► ERP          and the same business rules
e-shop ──────► WMS          (VAT codes, payment methods, addresses)
marketplace ─► WMS          copied into each of them
B2B portal ──► WMS

Each new system adds several mappings. Each change to a business rule has to be made in several places, and sooner or later one of them is forgotten.

The pattern: map once to a shared model

A canonical data model is your organisation’s own, system-independent definition of a business object. Each source maps to it, each target maps from it:

e-shop ──────┐                 ┌──► ERP
marketplace ─┼──► canonical ──┼──► WMS
B2B portal ──┘     order       └──► (next system)

Three sources and two targets now need five mappings instead of six, and the gap grows quickly: with five sources and four targets it is nine instead of twenty. More importantly, a new target needs one new mapping, and replacing the ERP touches one mapping.

Design rules that keep it useful

• Model the business, not a system. Call it customer.vatNumber, not AFM or billing_vat. Use your own codes for things like payment methods, and translate system codes at the edges.
• Start small. Include the fields that at least two flows need. A canonical order with 25 well-defined fields is more useful than one with 300 optional ones.
• Be explicit about formats. Dates in ISO 8601, amounts with a decimal point and a currency, country codes in ISO 3166. Decide once, document it.
• Version it. Add optional fields freely, but treat removing or renaming a field as a breaking change.
• Give it an owner. One person or team approves changes, otherwise it becomes the union of everyone’s wishes.

A short example of a canonical order:

{
  "orderNumber": "ESHOP-58213",
  "source": "ESHOP",
  "orderDate": "2026-10-23T09:14:00+03:00",
  "customer": { "customerId": "C-1042", "name": "Papadopoulos SA", "vatNumber": "EL099999999", "email": "orders@example.gr" },
  "payment": { "method": "CARD", "status": "PAID" },
  "currency": "EUR",
  "lines": [
    { "sku": "SKU-771", "quantity": 2, "unitPrice": 24.90, "vatRate": 24 }
  ],
  "shipTo": { "street": "Ermou 10", "city": "Athens", "postalCode": "10563", "country": "GR" }
}

Building it in Boomi

In Boomi, a canonical model is made of ordinary components, organised so they are shared: a profile for the canonical format, maps to and from it, and sub-processes that hide each system behind the model.

Step 1: Create the canonical profile

1. Create a folder for shared components, for example Canonical/Order, so everyone knows where the model lives.
2. Create a JSON profile (or an XML profile, if your team prefers XML) named something like Canonical Order v1. You can import the example above to generate the structure, then review types and mark the mandatory elements.
3. Add a short description in the component, with a link to the documentation of each field.

Step 2: Inbound maps (source to canonical)

For each source, create one Map component from the source profile to the canonical profile: E-shop Order to Canonical Order, Marketplace Order to Canonical Order and so on. This is where source-specific translation happens: field names, date formats, and code lists such as payment methods.

Keep code translation in cross reference tables rather than hard-coded in each map, so the e-shop’s cod and the marketplace’s CASH_ON_DELIVERY both become COD in one maintained place. See Cross reference tables in Boomi and, for mapping technique in general, Maps and profiles in Boomi.

Step 3: Outbound maps (canonical to target)

For each target, create one map from the canonical profile: Canonical Order to ERP Sales Order, Canonical Order to WMS Shipment. These maps know nothing about where the order came from. The ERP map translates COD to the ERP’s own payment code, the WMS map ignores prices entirely.

Step 4: Wrap targets in sub-processes

Create one sub-process per target that accepts a canonical order: Deliver Order to ERP, Deliver Order to WMS. Each one contains the outbound map, the connector call and its own error handling. Source processes call them with a Process Call shape (or route to them with a Process Route shape if you want to choose the target dynamically).

A source process then becomes short and uniform:

Fetch e-shop orders ──► Map: e-shop → canonical ──► Process Call: Deliver Order to ERP
                                                └─► Process Call: Deliver Order to WMS

When the ERP is replaced, you rebuild one sub-process. Every source keeps working.

Step 5: Validate at the canonical boundary

Add a validation step right after each inbound map, for example a Business Rules shape or a Decision on the mandatory fields. If a source sends an order without a VAT number for a B2B customer, it is rejected at the edge with a clear message, instead of failing later inside the ERP call.

Before you go live

• Write the field dictionary. One line per field: meaning, format, example. The profile alone doesn’t explain intent.
• Check component reuse. Make sure processes reference the shared profile and maps, not copies. Copies drift.
• Plan changes. When you need Canonical Order v2, create it next to v1 and migrate flows gradually.
• Don’t force everything through it. A one-off flow between two systems that no one else uses can map directly. The canonical model is for objects many flows share.

If your challenge is less about message formats and more about which system holds the “true” customer or product record, look at master data management, starting with our master data management guide.

Summary

A canonical model replaces many pairwise mappings with one mapping per system, and puts shared business rules in one place. In Boomi it is built from ordinary components: a shared profile, one inbound map per source, one outbound map per target, and sub-processes that hide each target. For more patterns like this, see Integration patterns every team should know.