The same record can look different in each application.
Consider a product used by a commerce platform, an operations system and a support tool. One application may organize it around a sellable variant, another around a stock item and another around the description a customer sees.
The labels may look similar while the records serve different purposes. Moving a field from one place to another does not establish that the two fields mean the same thing. A useful integration begins by defining the business relationship.
The example in this guide is illustrative. It does not reproduce the schemas of Shopify, Odoo, Zendesk or an ECH02 customer implementation.
Start with identity and ownership.
Ask two questions before mapping fields: how do we know these records refer to the same thing, and which application is responsible for each piece of information?
A shared identifier can connect records, but it still needs a rule for creation, matching and change. A product name is often a poor substitute for an agreed identifier because names can vary. If a match is uncertain, the workflow needs a defined way to handle it.
Ownership can differ by field. One application might own a description while another provides the stock figure used by the process. Record those decisions explicitly so a later update does not silently overwrite the intended source.
Make the mapping visible.
| Shared concept | Question to resolve | Illustrative rule |
|---|---|---|
| Product identity | Which records refer to the same item? | Use an agreed identifier and retain each system's reference. |
| Price | What amount, currency and context does it represent? | Store the amount with its currency and relevant price context. |
| Stock | Does the value mean physical, available or reserved stock? | Name the quantity's meaning and the location it applies to. |
| Status | Which states can the workflow act on? | Map known states and handle unmapped values explicitly. |
| Update ownership | Which source may change the value? | Assign an owner and define how conflicting updates are handled. |
This table is a starting point for a discussion. The right fields and rules depend on the actual applications and the business action being implemented.
What a canonical model contributes.
A canonical model provides a common representation between applications with different formats. Each connection maps between its application and that shared representation. The Canonical Data Model pattern describes this approach as a way to reduce direct dependencies between individual application formats.
The pattern adds a translation layer. With only a few simple connections, that layer can be additional work; its value depends on the number and nature of the relationships. It should be chosen for the integration problem rather than treated as a universal requirement.
Keep the model close to the work.
A useful starting model contains the information required by the process being built. Trying to represent an entire organization before implementing one workflow can make the first scope difficult to complete and evaluate.
For a price-change workflow, begin with the records and context needed to describe that change correctly. Add other concepts when a defined process requires them. This keeps the discussion connected to real examples and helps the team identify where a shared definition is doing useful work.
A mapping workshop needs real examples.
Bring representative records from each participating system, the action you want to perform and the person who understands the business meaning. Include an awkward example: a missing reference, a conflicting value or a record that does not fit the usual pattern.
Plan for changes and unresolved cases.
Agree how a new field or changed meaning will be introduced. A connection can continue transporting data while its interpretation becomes incorrect. Reviewing changes to definitions is therefore part of maintaining the workflow.
Also decide what happens when data cannot be mapped confidently. The useful response depends on the task: it might pause a change, show a review item or ask for a missing value. Specify the behavior and test it with representative records.
How this fits the ECH02 approach.
ECH02 uses a canonical layer alongside reusable nodes, a composer and a flow engine in its integration approach. The common structure supports the relationship between information and workflow steps. The mappings and business rules remain specific to the implementation.
For a new project, we explain which definitions and components can be reused, which connections need adapting and which cases require new work. That is the practical discussion behind making business systems work together.
Reference
Gregor Hohpe and Bobby Woolf: Canonical Data Model, Enterprise Integration Patterns. The mapping table and scoping questions above are ECH02's illustrative explanation, rather than an actual vendor schema or customer dataset.