Skip to main content

Part 2: The DataHub Golden Customer Record

DataHub is the deterministic system of record at the center of this consolidation. In this part you work through the CustomerGolden360 model — its fields, three contributing sources, three-tier match rules, and survivorship — and the repository it is deployed to. This is DataHub's native lane: match, merge, survivorship, and golden records. The agent you build later stays entirely out of it.

You will drive this part with Companion prompts, the same way you drafted the model in Part 1. Which prompts you run depends on where you are working. In the shared workshop account the model is already built, so you run the introspection prompts — Companion reads the live model back to you and you verify each design decision against it. The creation prompts that produced the model are included at each step for participants building in their own trial (see the appendix); in the shared environment they are unnecessary — do not run them.

Shared environment — introspect, don't rebuild

In the shared workshop account the CustomerGolden360 model and repository are already built for you. Use the introspection prompts below to explore how the model, sources, and match rules are constructed, but do not create, re-publish, or re-deploy the model here — that changes matching for everyone in the room. To build it yourself for real, use your own free trial — see Appendix: Build the DataHub Model in Your Own Trial.

Add the Data Hub Credentials to your .env file​

Your Claude Code instance with Companion knows how to access Boomi's basic platform APIs, but the Data Hub APIs are separate from the main platform and require different authorization. To grant access, we need to make sure your basic .env file has the necessary credentials to see, read, and modify things in Data Hub.

  1. Uncomment or add the following variables to your .env file:

    • DATAHUB_REPO_URI
    • DATAHUB_REPO_USERNAME
    • DATAHUB_REPO_AUTH_TOKEN

  2. Login to https://platform.boomi.com

  3. From the Home Page select "Data Hub".

  4. Select the "Customer360MA" Repository

  5. Open the "Configure" tab at the top of the screen

  6. From the Confugration page, copy the three values into the variables you just added to your .env file.

    • DATAHUB_REPO_URI - Base URL for API Requests
    • DATAHUB_REPO_USERNAME - Username
    • DATAHUB_REPO_AUTH_TOKEN - My Hub Authentication Token

  7. Save your .env file.

The Customer Model and Its Fields​

  1. Ask Companion to describe the model:

    Using Boomi Compaion describe the CustomerGolden360 model in the Customer360MA repository — list its fields and their types, the record title, and the natural key.

  2. Confirm the model has 13 fields with legalName as the record title.

    recordId is the natural key

    The model root reserves id, which is why the model carries a separate recordId field as the natural key. The 13 fields are recordId, legalName, dbaAliases, parentLegalName, country, taxId, contractValueUsd, paymentTerms, renewalDate, products, primaryContact, acmeCustomerId, and betacorpAccountId.

    Own-trial only — create the model

    This creation step is unnecessary in the shared environment — the model already exists. If you are building in your own trial, create it with:

    Using Boomi Companion create a DataHub master data model called CustomerGolden360 for a golden customer record based on the plan we just created and saved in this directory.

The Three Contributing Sources​

  1. Ask Companion to list the sources:

    Using Boomi Compaion list the contributing sources on the CustomerGolden360 model — their names, their type, which one is the default, and whether create or update approvals are required.

  2. Confirm three sources: ACME_SFDC (default), BETACORP, and AGENT_CANDIDATE — all type Both, no approvals required.

    The agent only ever publishes to AGENT_CANDIDATE

    The agent you build in Part 4 publishes its extracted candidate records into the AGENT_CANDIDATE source and nothing else. DataHub owns match, merge, and survivorship across all three sources. The agent never enters that lane.

    Own-trial only — add the sources

    This creation step is unnecessary in the shared environment. If you are building in your own trial, add them with:

    Using Boomi Compaion add three contributing sources to this Customer model based on our plan: "ACME_SFDC" for Acme's Salesforce/Marketo golden records (default source), "BETACORP" for the acquired BetaCorp Dynamics/SAP feeds, and "AGENT_CANDIDATE" for records published by the Unstructured Onboarding Analyst agent. All three should be type Both, no create/update approval required.

The Three-Tier Match Rules​

The match rules decide when two incoming records are treated as the same legal entity. They evaluate in order, most-restrictive first, and the first satisfied rule wins.

  1. Ask Companion to walk the match rules:

    Using Boomi Compaion show me the match rules on the CustomerGolden360 model in order — what each tier matches on and why the order matters, most-restrictive first.

  2. Confirm the three tiers are in order:

    1. Exact match on acmeCustomerId — a candidate carrying a known Acme customer id matches its golden record.
    2. Exact match on taxId — the same tax id means the same legal entity.
    3. Exact match on country AND Jaro-Winkler match on legalName ≥ 0.92 — the fuzzy name path, gated by country.
    Own-trial only — add the rules and publish the model

    This creation step is unnecessary in the shared environment. If you are building in your own trial, add the rules with the prompt below, then publish the model as version 1 once the fields, sources, and rules are in place:

    Using Boomi Compaion add match rules to CustomerGolden360 so records merge only when they are truly the same legal entity. Rule order, most-restrictive first: (1) exact match on acmeCustomerId; (2) exact match on taxId; (3) exact match on country AND a fuzzy Jaro-Winkler match on legalName with tolerance 0.92. The country gate plus the high name tolerance must keep "Stark Industries" (US) and "Starke Industrial GmbH" (Germany) as separate golden records, and must NOT auto-merge an ambiguous "Starke Ind." note into either.

Why the 0.92 threshold keeps Stark and Starke distinct​

The deliberate near-duplicate in this lab is Stark Industries (United States, tax 52-1900001) versus Starke Industrial GmbH (Germany, tax DE-2099887766). They must stay as two separate golden records, and an ambiguous "Starke Ind." note must not auto-merge into either.

  • "Starke Ind." carries no acmeCustomerId and no taxId, so Rules 1 and 2 cannot fire.
  • Under Rule 3, only Stark Industries shares the country gate (US); Starke Industrial GmbH (Germany) is blocked by the country gate entirely.
  • The Jaro-Winkler similarity of "Starke Ind." against "Stark Industries" is approximately 0.876, which is below the 0.92 threshold — so no match.
  • Result: "Starke Ind." matches neither and routes to a steward exception. This is the engineered governance outcome you see in Part 6.

Why taxId is the safety net​

A high name threshold like 0.92 is deliberately strict, and it will reject some legitimate matches whose names look different on paper. Globex Corp. versus Globex Corporation has a Jaro-Winkler similarity of about 0.906 — below 0.92, so the fuzzy name rule would miss it. But both records share tax id 77-2048817, so Rule 2 (taxId exact) catches the match before the fuzzy rule is ever reached. The taxId tier is the safety net that lets you keep the name threshold strict without losing real matches.

The Deployed Repository — and the Data Itself​

  1. Ask Companion to describe the repository and then look at the golden data:

    Using Boomi Compaion describe the Customer360MA DataHub repository — which Hub Cloud it runs on and the deployment status of the CustomerGolden360 model. Then query a few golden records and show me what the data looks like.

  2. Confirm the repository is on the USA East Hub Cloud, the model deployment status is SUCCESS, and the golden records Companion returns carry the fields you explored above.

    Deployed-universe runtime path

    Once deployed, the model is addressable as a universe at the runtime path prefix /mdm/universes/<universe-id>/... on the Hub Cloud host. Integration (Part 3) and the agent's publish API both write into this universe.

    Own-trial only — create and deploy the repository

    This creation step is unnecessary in the shared environment. If you are building in your own trial, create and deploy with:

    Using Boomi Compaion create a new DataHub repository named Customer360MA on the USA East Hub Cloud and deploy the published CustomerGolden360 model to it.

What You Now Have​

  • The CustomerGolden360 golden Customer model, published as version 1 — introspected field by field (or built with your own hands in your own trial).
  • Three sources: ACME_SFDC (default), BETACORP, and AGENT_CANDIDATE.
  • Three-tier match rules engineered to keep Stark and Starke distinct while catching Globex via taxId.
  • A deployed repository with live golden records you have already queried.
The deterministic core is in hand

You have walked DataHub's golden Customer record — the deterministic system of record the acquisition was missing. The match rules are tuned so near-duplicates stay distinct and legitimate matches are never lost. In the next part, you will onboard BetaCorp's structured sources into this model.