Skip to content

Canonical Data Model in Orchestrations

The Canonical Data Model (CDM) is central to how DIBOP transforms data between systems. This page explains how the CDM integrates with orchestrations and why it matters for your workflows.

The N-to-N Problem

Without a canonical model, connecting N systems requires N x (N-1) direct mappings. For 5 systems, that is 20 mappings. For 10 systems, it is 90. Every new system multiplies the effort.

The CDM solves this by introducing a single shared schema. Each system maps to and from the CDM -- not to every other system. For N systems, you need only 2N mappings (one inbound, one outbound per system).

Without CDM:                    With CDM:
A ←→ B                         A ←→ CDM ←→ B
A ←→ C                         C ←→ CDM ←→ D
A ←→ D                         E ←→ CDM
B ←→ C
B ←→ D                         (5 systems = 10 mappings)
C ←→ D
(4 systems = 12 mappings)

How the CDM Works in Orchestrations

When you build an orchestration that moves data between two systems, the CDM acts as an intermediate format:

  1. Inbound Mapping: The source connector maps its native fields to CDM fields
  2. Orchestration Logic: Your steps work with CDM fields (consistent, predictable)
  3. Outbound Mapping: The target connector maps CDM fields to its native format

Example: Vehicle Sync

OEM Portal                      CDM (Vehicle)                    DMS
-----------                     -------------                    ---
vehicle_id        ──>           vin                    ──>       stock_vin
fahrzeug_marke    ──>           make                   ──>       veh_make
modell_name       ──>           model                  ──>       veh_model
baujahr           ──>           year                   ──>       model_year
kilometerstand    ──>           mileage_km             ──>       odometer

Each connector handles its own mapping to/from the CDM. Your orchestration works with the CDM fields -- vin, make, model, year -- regardless of which systems are involved.

CDM Domains

The CDM is organised into domains, each representing a business entity. DIBOP currently supports 22 domains:

Domain Description
Vehicle Core vehicle data (VIN, make, model, year, specs)
Customer Customer records (name, contact, address)
Order Sales and purchase orders
Workshop Job Service and repair jobs
Part Parts catalogue and inventory
Lead Sales leads and opportunities
Vehicle Inspection Inspection records and results
Appointment Scheduled appointments
Shipment Shipping and delivery records
Location Physical locations (dealerships, warehouses)
Parking Event Vehicle parking and storage events
Vehicle Location Real-time vehicle positions
Deal Completed sales transactions
Employee Staff records
Finance Agreement Financing and leasing contracts
Payroll Run Payroll processing records
EOL Vehicle End-of-life vehicle records
Auction Transaction Vehicle auction records
Title Record Vehicle title and registration
Recycler Part Recycled/salvage parts
Depollution Record Environmental compliance records
Compliance Check Regulatory compliance verifications

See Available Domains for detailed field lists.

Using CDM Fields in Steps

In API Call Steps

When an API Call step communicates with a connected system, the connector automatically handles the mapping. You work with CDM field names in your orchestration, and the connector translates them to the system's native format.

In Transform Steps

Transform steps can reference CDM fields to reshape data:

{
  "vehicle_summary": "${fetch_vehicle.vin} - ${fetch_vehicle.make} ${fetch_vehicle.model} (${fetch_vehicle.year})",
  "contact_info": "${fetch_customer.email}",
  "is_recent": "${fetch_vehicle.year} >= 2023"
}

In Conditional Steps

Use CDM fields in conditions:

Condition: ${fetch_vehicle.mileage_km} > 100000
  Then: → flag_high_mileage
  Else: → standard_processing

PII Classification

Every field in the CDM is classified for PII (Personally Identifiable Information) sensitivity:

Classification Meaning Examples
None Not personally identifiable Vehicle make, model, year
PII Personally identifiable Customer name, email, phone
Sensitive PII Highly sensitive Government ID, financial account numbers

PII classification is visible in the Canonical Explorer and affects how data is logged and retained.

PII in Logs

DIBOP automatically redacts PII fields in execution logs and API call logs. You will see masked values (e.g., j***@example.com) instead of the actual data.

Mapping Coverage

Not every connector maps every CDM field. The mapping coverage tells you how completely a connector supports a given domain:

  • Full coverage: The connector maps all required and optional fields
  • Partial coverage: The connector maps required fields and some optional fields
  • Minimal coverage: The connector maps only the required fields

You can view mapping coverage in the Canonical Explorer and on each connector's detail page.

AI-Assisted Mapping

When configuring a new connector, DIBOP's AI can assist with field mapping:

  1. Paste a sample JSON response from the external system
  2. DIBOP's AI analyses the fields and suggests CDM mappings
  3. Review and approve or adjust the suggestions
  4. Mappings are classified as Verified (manually confirmed) or Assumed (AI-suggested, not yet confirmed)

See Field Mapping for the full workflow.

Best Practices

  1. Always work with CDM fields in orchestrations -- do not reference native system fields directly, as this ties your orchestration to a specific connector
  2. Check mapping coverage before building an orchestration -- if a connector does not map the CDM fields you need, the orchestration will have gaps
  3. Verify AI-suggested mappings -- AI suggestions are usually correct but should be confirmed for critical fields
  4. Use the Canonical Explorer to understand which fields are available before you start building

Next Steps