MDM Studio — Step‑by‑Step: Build a Domain from Scratch to Reports

Adaptive Canvas · Step-by-step: Domain to Reports
Release v1.2.0

MDM Studio — Step‑by‑Step: Build a Domain from Scratch to Reports

Adaptive Canvas · Enterprise Master Data Management Release v1.2.0 · DESIGN · MAP · GOVERN · TRUST

How to use this manual

This manual walks you through the complete journey of standing up a new master‑data domain in MDM Studio — from the very first click to a published report — in the order you actually do it. Follow the steps top to bottom; each one builds on the one before.

We use a single running example throughout: a Customer domain, mastered from two source systems (a CRM and a billing database) into trusted golden records, then reported on. Wherever you see Customer, CRM or Billing, substitute your own names.

Conventions

Three things about the interface, before you go looking for something that is there

  1. Your sidebar is shaped by your role. There are nine destinations: Home, Modelling Studio, Integration Hub, Quality, Mastering, Governance, Analytics, Administration, Help. Admins, developers and viewers see all nine at the top level. If you sign in as a Steward, Data Owner or Analyst, three of them — Modelling Studio, Integration Hub and Administration — are tucked inside a collapsed Engineering disclosure at the bottom of the sidebar. Click Engineering to open it. Everything in this manual is reachable; some of it is one click deeper for you.
  2. Trees and groups start collapsed. The first time you open My Work, Jobs & Runs, Job Groups, Change Requests, the DQ Rules browser or the Exceptions tree, every group is folded shut. An empty‑looking tree is a collapsed tree, not an empty one — expand a group to see its rows. After that first visit each page restores whatever you last left open, so "expand all" sticks.
  3. Right‑click a row. Every grid in this walkthrough carries a row context menu — open the record, open it where it lives, trace it, filter by the value in the column you clicked, copy the key, delete it. Destructive items hand off to the page's own confirmation dialog rather than acting on the spot, and a greyed item tells you in words why it is unavailable.

The journey at a glance

The thirteen numbered steps below are the whole flow, in order:

  1. Prepare — sign in, open a working model, check it out.
  2. DESIGN — create the domain.
  3. Add entities.
  4. Define attributes in the Data Dictionary.
  5. Relate & define — ERD relationships, glossary, catalog (recommended).
  6. MAP — register the source system and its connection.
  7. Map fields in the Mapping Designer.
  8. Standardize — cleansing rules on the way in.
  9. Ingest — run the load and stage the data.
  10. TRUST (quality) — profile, add quality rules, clear exceptions.
  11. TRUST (master) — matching, survivorship and golden fields.
  12. GOVERN — publish and review golden records; write back.
  13. Report — build the report, publish it, confirm pipeline health.

Before you start — the platform has to have a model

Role: Admin (this section is done once, by whoever installed the platform).

A brand‑new install has no working model, and with no active working model every write outside the global routes fails with HTTP 409 — "No working model is active." Domains, entities, attributes, mappings, rules: all of them 409 until a model exists and is active. If you have just installed MDM Studio and nothing will save, this is why.

The bootstrap sequence, in order:

  1. Migrate. Run the database migrations against your hub engine so the mdm and audit schemas exist.
  2. Seed. Run npm run demo:seed for a small, idempotent, DEMO_‑prefixed starter set stamped into the active model; demo:sample for bulk raw rows; demo:full for a complete four‑domain worked solution built through the product's own REST API. Seeding is optional — but a fresh, unseeded install cannot show you golden records, GR Explorer, Record Timeline, Report Center, Write‑Back or the Catalog, because all of those read the output of a completed pipeline.
  3. Create and activate a model — Step 1 below.
  4. Check the model out — Step 1 below.
  5. Build — Steps 2 onwards.

Note. demo:sample rewrites three cap keys in .env (the survive and publish row caps) and needs an API restart afterwards to pick them up.

Step 1 — Prepare your workspace

Where: Header · Administration → Platform → Deployment Models Role: Any role can sign in; creating and checking out a model needs Developer, Data Owner or Admin.

Before you can model anything you need to be signed in, pointed at a database engine, and working inside a model you have checked out.

  1. Sign in. Open MDM Studio. If your platform hosts more than one tenant, pick your tenant first, then enter your username and password — or use Active Directory, SAML or OIDC sign‑in if your tenant is configured for it. (SAML and OIDC are inactive unless their environment settings are set; Local and per‑tenant AD are always available.)
  2. Pick the hub engine. The sign‑in page shows the active hub engine on a badge before you sign in, and an engine selector beside it — choose SQL Server, PostgreSQL, MySQL or Oracle here. Two things in this manual depend on which you pick: write‑back is not available on Oracle (Step 12), and a model's target database is provisioned automatically on SQL Server, PostgreSQL and MySQL. The engine stays visible in the header for the rest of your session.
  3. Create or open a working model. A model is the versioned container for your whole design — domains, entities, dictionary, mappings and rules. Go to Administration → Platform → Deployment Models. Create a model empty, clone it from an existing one, or import it from XML. On the create form, set the MDM pattern (Registry / Consolidation / Coexistence / Transaction) and, if you use them, the four hierarchy tier names — a tier advisor will propose a set from your industry.
  4. Activate it. Make the model active from the model selector in the header. Until a model is active, writes 409.
  5. Check the model out. Structural editing requires an exclusive checkout. Use Check out in the header (or the model lock control on Deployment Models). While it is checked out to you, you can edit structure; everyone else sees the model read‑only.
  6. Open My Work. Go to Home → My Work. This is your inbox for everything the platform queues to you personally — change requests, exceptions, match reviews, campaigns, real‑time reviews, workflow approvals, survivorship conflicts, comparison conflicts, expiring rule suspensions and noisy‑rule proposals — ranked by SLA, each with a deep link straight to the item and a personal snooze. Come back here after every step in this manual; it is where the work you generate lands.

▶ The header shows your tenant, the active model, the engine and a checked‑out indicator. My Work opens (collapsed — expand a group). You're ready to design.

Tip — the checkout lock is stricter than it looks. Structural writes need a checkout even when nobody holds the lock; "nobody has it" is not the same as "you have it". If someone else holds it, the whole model is read‑only to you and every structural write returns HTTP 423. Read‑class operations — preview, test, score, validate, impact analysis, catalog ask — always pass, checkout or not.

Tip — check‑in is a review, not just an unlock. Checkout snapshots about twenty model‑scoped tables. When you check in, MDM Studio diffs your work against that snapshot and lets you accept or reject each change individually; rejects are reverted in one FK‑ordered transaction.

Tip — review bypass. A new model usually starts with review bypass on, so first‑time setup isn't blocked by approval workflow. While it is on the header is amber and an amber Review bypass ON pill sits next to the checkout control — that is the studio telling you governance is suspended, not that everything is fine. Once the domain is live, turn the bypass off (from the pill, or the model's row in Deployment Models) and governed changes start routing through review. Only an Admin or Developer can flip it.

Tip — follow the map. The Getting started card on Home tracks these setup steps live and ticks them off as you complete them. And the pipeline strip — on every hub landing, plus Home, Data Profiling and As‑Is Assessment — deep‑links to each stage of the flow, so you can jump straight to the step you are on instead of hunting for the tab.

Step 2 — Create the domain

Where: Modelling Studio → Design → Domains & Entities → Domains Role: Developer / Data Owner / Admin

A domain is the top‑level subject area you are mastering — Customer, Product, Supplier, Employee. It's the folder everything else in this manual lives under.

  1. Open Modelling Studio from the sidebar (stewards, data owners and analysts: it's inside Engineering), then the Domains & Entities screen, and select the Domains sub‑tab.
  2. Click New.
  3. Give it a name (e.g. Customer), a display name and a short description, and pick its data steward and data owner (both required) from the dropdowns. These two people become the domain's Responsible and Accountable parties in the catalog, and they are who unassigned exceptions auto‑route to later.
  4. (Optional) Set a default sensitivity level — Public, Internal, Confidential or Restricted. Everything under the domain inherits it, and the effective level of any attribute is the most restrictive value on the domain → entity → attribute chain. For a Customer domain, Internal is a sensible floor.
  5. Save.

▶ Customer appears in the domains list. This is the anchor for entities, mappings, matching, survivorship and reporting.

Note — licence capacity is enforced here. Domain count is one of only two things the licence actually stops you doing (the other is user count). Community allows 3 domains, Professional 25, Enterprise unlimited. Over the limit, Save returns HTTP 402 — licence limit.

Tip. Right‑click a domain row for open, filter, copy and delete. Deleting a domain is a governed change: with the review bypass off it raises a change request rather than deleting anything immediately.

Step 3 — Add entities to the domain

Where: Modelling Studio → Design → Domains & Entities → Entities Role: Developer / Data Owner / Admin

An entity is a master object inside the domain — for Customer that's typically Customer itself, and perhaps Address and Contact. Each entity becomes a table of golden records at the end.

  1. In Domains & Entities, switch to the Entities sub‑tab.
  2. Click New, and select the parent domain (Customer).
  3. Name the entity (e.g. Customer), set its display name and description.
  4. (Optional) Raise the entity's sensitivity level above the domain default if this object is more sensitive than its siblings.
  5. (Optional) Bind the model's hierarchy tiers to attributes on this entity. Bound tiers are materialised as _tier1…_tier4 columns, stamped at every pipeline stage and carried onto the golden record — which is what makes "quality by tier" and the survivorship decision matrix work later.
  6. Save, and repeat for any additional entities (Address, Contact).

▶ Your domain contains one or more entities, each ready to receive attributes.

Shortcut — Schema Importer. If your structure already exists in a database, use Modelling Studio → Design → Model Builder → Schema Importer to reverse‑engineer tables and columns into entities and attributes in one pass (saved queries included), then refine them in Step 4 instead of typing everything by hand. Model Builder itself offers AI or heuristic naming with live previews.

Step 4 — Define attributes in the Data Dictionary

Where: Modelling Studio → Document → Data Dictionary Role: Developer / Data Owner / Admin

The Data Dictionary is where each entity's attributes (fields) are defined. This is the single most important design step — matching, survivorship, quality and masking all read from here.

  1. Open Data Dictionary and select your entity (Customer).
  2. Add each attribute with New. For every attribute set:
    • Name and display name (e.g. first_name, last_name, email, phone, customer_number).
    • Data type (string, number, date, boolean, …) and length/format where relevant.
    • Key / identifier flags — mark the business/natural key (e.g. customer_number) and any unique identifiers. These guide matching.
    • Required where the field must be present.
    • Sensitivity level — Confidential on fields like email and phone, Restricted for anything that should hide the whole record. Classification is defined here and enforced at serve time (Step 11 note).
  3. (Optional) Use AI Suggestions. The attribute editor can propose business names and display names for you from the technical column names. It reports which engine answered: with an AI key configured it runs llm+heuristic; with no key it runs heuristic alone and keeps working. Either way it only proposes — nothing changes until you accept a suggestion. The same suggester is available in the entity list and in Model Builder.
  4. Save each attribute.
  5. (Optional) Register attribute sources — which source system and column each attribute is fed by. These feed source‑to‑target mapping in Pipeline Health and the write‑back eligibility list; without them those two screens have nothing to show.

▶ Each entity has a complete, typed, classified set of attributes. This is your canonical model.

Tip. Decide your business key deliberately (customer_number, or email if that is your true identifier). Everything downstream — mapping targets, match rules, survivorship — refers to these attributes by name.

Tip. Right‑click an attribute row and choose open where it lives to jump straight to the entity or domain that owns it, or filter by this value to narrow the grid to the column you right‑clicked.

Step 5 — Relationships, glossary and catalog (recommended)

Where: Modelling Studio → Design → Data Modelling · Plan → Business Glossary · Document → Catalog Role: Developer / Data Owner / Admin

  1. Draw the relationships. Open Modelling Studio → Data Modelling. This is the ERD canvas, and it is where relationships are created and edited — drag between two entities to relate them (a Customer has many Addresses). Auto‑layout offers a compact grid or a fully expanded arrangement. There is no Relationships tab on the tab bar; the ERD canvas is the way in.
  2. Confirm the shape. Still on the canvas, check that cardinality and the FK columns are what you intended. GR Explorer (Step 12) walks the golden set through exactly these relationships, so a wrong join here shows up as a wrong tab there.
  3. Define the words. In Business Glossary, add plain‑language definitions for key terms — what "active customer" means, how "primary email" is chosen. Terms move DRAFT → PUBLISHED through approval. Relate terms to each other with typed relations (SYNONYM, RELATED, BROADER, NARROWER, SEE_ALSO) and bind them to the entities and attributes they govern.
  4. (Optional) Set a masking policy on a term. A glossary term can carry one of five masking shapes — FULL, FIRST_INITIAL, YEAR_ONLY, LAST4, EMAIL_DOMAIN — which decides what a redaction looks like for every asset bound to that term. It does not decide whether redaction happens; that is settled by sensitivity level versus the reader's clearance. Where two terms disagree, the most restrictive wins and the loser is reported.
  5. (Optional) Open the Catalog. Modelling Studio → Catalog is the internal read model projected over everything you have just built — assets, coverage, facets, and proposals a steward can accept or reject. Its Owner and Steward facets are named Accountable and Responsible; Consulted and Informed are set here too, and they matter in Step 12.

▶ Your model is designed, related and documented. Time to bring in real data.

Note — catalog search is lexical. Out of the box the catalog's search ranking is deterministic (exact, name, synonym, URN, related, description) and its embedder is a local token‑and‑trigram hash. It matches shared words and shared word shapes — "customer" finds "customers" — and nothing beyond that. It is not a semantic index unless a remote embedding model is configured, and it says so in its own status panel.

Note — the catalog index rebuilds on demand. Press Reindex after a burst of modelling. Connections, mapping sets, relationships, attribute sources and trust scores change the model silently without emitting a change marker; the status panel lists them under "sources not emitting".

Step 6 — Register the source system and connection

Where: Integration Hub → Configure → Sources & Connections Role: Developer / Data Owner / Admin

A source system is where raw records come from; a connection is the credentials used to reach it.

  1. Open Integration Hub from the sidebar (stewards, data owners and analysts: inside Engineering), then Sources & Connections.
  2. On the Source Systems sub‑tab, click New and describe the system (e.g. CRM, Billing). Set its trust score — this is the number MOST_TRUSTED_SOURCE survivorship reads in Step 11, so set it with that decision in mind. A deterministic trust advisor will propose scores from what it can observe.
  3. On the Connections sub‑tab, click New and choose the connection type. Fifteen are supported: SQL Server, Azure SQL, Synapse, PostgreSQL, MySQL, Oracle, Teradata, Snowflake, BigQuery, Databricks, Salesforce, CSV, Excel, FTP and REST API.
  4. Enter the connection details (host, database, credentials, or the file/endpoint) and Test the connection. Credentials are envelope‑encrypted into the secrets vault, not stored in the clear.
  5. Save. Repeat for each source — do the CRM first, then Billing.

▶ Each source shows a tested connection. You can now map its fields to your model.

Note — five connectors ship as optional dependencies. The drivers for Snowflake, BigQuery, Databricks, Salesforce and Teradata are optional packages loaded on demand. A stock install that was not built with them cannot connect to those five, and the test will fail on a missing module rather than on your credentials. Install the driver package on the API host and restart, then re‑test.

Note. Connections are one global registry replicated across every enabled hub engine — define a source once and reuse it everywhere.

Tip. Right‑click a connection or source system row for open, filter by this value, copy and delete.

Step 7 — Map source fields to your model

Where: Integration Hub → Configure → Mapping Designer Role: Developer / Data Owner / Admin

The Mapping Designer is where you say "this source column becomes that model attribute."

  1. Open Mapping Designer.
  2. Create a new mapping set and choose the source (e.g. CRM) and the target entity (Customer).
  3. Load the source's columns, then map each source column to the target attribute you defined in Step 4 (e.g. CRM EmailAddr → email, CustNo → customer_number).
  4. Apply per‑field transforms where the shapes differ (trim, concatenate first/last name, cast a date), and set per‑field trust where one source is better than another on a specific column.
  5. Note the stage. Mapping sets are stage‑aware: an Extract set reads from the source; every later stage — Land → Stage → Standardize → Match → Survive → Publish — reads the previous stage's output. Stage isolation is enforced, and the create form only offers valid choices.
  6. Decide the set's loading behaviour — pick a date column for delta (incremental) loads, or acknowledge a full load; the set carries a load‑expectation badge either way. Heed the amber warning if no key field is flagged.
  7. Save, then build a second mapping set for Billing into the same Customer entity.
  8. Click Build pipeline sets — MDM Studio generates the full stage‑to‑stage chain (Land through Publish) for the entity from your Extract sets, ready for jobs in Step 9.

▶ Every source has a saved mapping into your model and the stage pipeline is laid out end to end. Two systems now feed one entity — exactly what MDM is for.

Note — transforms execute, and approval freezes what runs. A per‑field transform (trim, casing, an expression) is applied by the pipeline's generated SQL — what you configure is what lands. Two transforms, CONCAT and LOOKUP, do not execute and the designer refuses to save them, with an alternative suggested. Separately: approving a mapping set freezes an immutable specification version, and the pipeline runs the approved version, not your editable draft. A set you never approve keeps running its draft. The Versions panel on the set tells you which of the two is live, with a field‑level diff when they diverge.

Step 8 — Add standardization (cleansing) rules (recommended)

Where: Integration Hub → Configure → Standardization Role: Developer / Data Owner / Admin

Standardization cleans and normalises values as they come in, so matching later has consistent data to work with.

  1. Open Standardization. It has three tabs, because reference data and managed values now live here rather than on pages of their own:
    • the main tab — cleansing cascades per attribute;
    • Reference Data (?tab=reference) — governed reference domains and their values, plus RDM releases;
    • Managed Values (?tab=managed) — the curated value lists cleansing rules look up.
  2. On an attribute, build an ordered cascade of steps — trim, case conversion, digits‑only, and REFLOOKUP against a managed value list or crosswalk. The steps run in the order you place them, so put trim before lookup.
  3. Add rules for the fields that vary between your sources — uppercase country codes, normalise phone formats, title‑case names, standardise email casing.
  4. (Optional) Run the Standardization Advisor for proposals derived from a profile run (Step 10). It is deterministic and shows its evidence; nothing is applied until you accept it.
  5. Save.

▶ Incoming values are normalised. Cleaner input means far better match results.

Note — the old pages are gone. Reference Data and Managed Values used to be screens of their own in the Integration Hub. They are tabs here now, and old bookmarks redirect.

Note — "delete" here is a soft delete. Removing a standardization rule raises a change request rather than dropping the rule outright. Expect it to appear in Governance → Change Requests, not to vanish.

Step 9 — Run ingestion

Where: Integration Hub → Operate → Jobs & Runs (orchestrate in Orchestration) Role: Developer / Data Owner / Admin

Ingestion executes your mappings and loads source records into the platform's staging area.

  1. Open Jobs & Runs. The job tree opens collapsed on a first visit — expand your domain to see its stages.
  2. Create the jobs: drag your mapping sets from the palette onto the jobs panel — tick several and drag once to create them all — or click + New job for the full form. Auto‑allocate can propose the missing jobs, and the right stages, with a confirmation preview.
  3. Run each job now, or schedule it with a cron expression. Watch the run to completion.
  4. Check the run result — rows read, rows loaded, warnings, rejects. The All Runs view keeps the full history across jobs, rules, matching and profiling.
  5. (Optional) Use Orchestration → Job Groups / Execution Packages to run multiple jobs together with dependency ordering. The Standard pipeline button packages an entity's stage jobs into one dependency‑chained, repeatable unit. Job Groups also open collapsed to domains only; stages appear when you reveal a domain.

▶ Source data is staged inside the platform under your Customer entity. You now have data to profile, quality‑check and master.

Tip. Re‑running an ingestion is safe and repeatable — this is how you keep the domain fresh on a schedule.

Note — scheduling in a fleet. The cron scheduler is evaluated every minute and is on by default on every host. In a multi‑instance deployment, turn it off on all but one host or every host fires every schedule.

Note — an interrupted run. Unless the durable job queue is enabled, a triggered run is a detached background task: if the API restarts mid‑run, that run is lost rather than retried. With the queue on, a run is claimed under a lease, heartbeated, retried with backoff and dead‑lettered, with one log row per attempt.

Step 10 — Profile and quality‑check the data

Where: Quality → Assess → Data Profiling, Placeholder Advisor · Measure → DQ Rules, Data Quality · Remediate → Exceptions, Campaigns Role: Steward / Data Owner / Admin (Analysts can review)

Before mastering, measure what you loaded and fix the obvious problems.

  1. Profile. Open Quality → Data Profiling and profile the Customer entity. You get completeness, cardinality, uniqueness, ranges, length distributions, top values, inferred format masks, detected semantic types, character composition and suggested checks. Profiling is strictly read‑only — it never changes a value.
  2. Check for placeholders. Open Placeholder Advisor. It reads the profile run and flags values that are pretending to be data — N/A, UNKNOWN, 000000, a repeated dummy email — specifically where they are acting as match keys. A placeholder in a match key merges strangers together. Review the evidence and apply only what you agree with; nothing applies on its own.
  3. Author rules. In DQ Rules, create validation rules (email matches an email pattern; customer_number is present and unique) and group them into a ruleset for the entity. The DQ Rule Advisor fills in dimension, operator, pattern and threshold from the rule name using a curated regex library covering emails, phones and identifiers — it is deterministic, and it explains each choice. Dry‑run a rule before you activate it. You can also promote a source check into a rule, or reflect a rule back to the source.

  4. Suspend a rule instead of switching it off. When a rule is misfiring and you need breathing room, use Suspend rather than deactivating it. A suspension is a window: it needs an end date and a mandatory reason, the rule stays configured and visible in its rule set, and it comes back by itself when the window expires. Two things to know:

    • A suspended rule is not a passing rule. It is reported as not evaluated — no pass rate, no exceptions, no side effects — and the entity's aggregate states how many rules it could not evaluate. It does not quietly improve your score.
    • Suspending is operational, not structural, so it does not need a model checkout.

    Expiring suspensions arrive in My Work as SUSPENSION_EXPIRY. Separately, a rule that passes 1% or less across three consecutive runs is proposed for suspension as NOISY_RULE_PROPOSAL — a proposal only. Nothing is suspended by it. 5. Measure quality. Open Data Quality to run the ruleset and get a quality score with a per‑dimension breakdown — completeness, validity, uniqueness and the rest — plus scorecards and scheduled delta runs. 6. Remediate. Failed rows land in Exceptions. The left tree groups open exceptions domain → entity, with dimension and severity drill‑downs under each entity; it opens collapsed, and it deep‑links, so you can hand someone a URL that lands on exactly the selection you are looking at. Work exceptions individually — assign, start, resolve, ignore, reopen — or bulk‑assign and bulk‑resolve. Unassigned exceptions auto‑route to the attribute's steward, then the entity's, then the domain's. 7. (Optional) Launch a Campaign (Quality → Campaigns) to batch exceptions out to stewards. Campaigns are created and updated through governance and have no delete — close them, don't expect to remove them. 8. Check My Work. Everything you just generated that has your name on it is now in Home → My Work, SLA‑ranked.

▶ You know your data's quality score, you know which rules were not evaluated, and the worst records are being worked. Ready to master.

Tip. Right‑click rows here too: a rule row offers open, open where it lives, filter and delete; an exception row offers the record it came from.

Step 11 — Configure matching, survivorship and golden fields

Where: Mastering → Configure → Mastering Rules (sub‑tabs Matching, Survivorship, Golden Fields) Role: Data Owner / Admin (Stewards review matches)

This is the heart of MDM: deciding which records are the same customer, and how to build the single trusted version.

  1. Matching. Open Mastering → Mastering Rules → Matching. Create a ruleset for Customer. Each rule carries a comparator, a weight, a threshold and a blocking key. The comparators are EXACT, NORMALIZED, PREFIX, FUZZY (Levenshtein), Damerau‑Levenshtein/OSA, Jaro‑Winkler, Metaphone and DATE_TOLERANCE. For our example: EXACT on customer_number, JARO_WINKLER on last_name, NORMALIZED on email, and block on the first three characters of last_name so the engine is not comparing everyone to everyone.
  2. Set the decision thresholds. Every scored pair resolves to AUTO_MERGE, REVIEW or NO_MATCH; REVIEW pairs go to a steward and land in My Work as match reviews. Run the deterministic Match Advisor if you want a proposed starting ruleset with its reasoning shown.

  3. Survivorship. On the Survivorship sub‑tab, define per entity and per attribute which value wins when duplicates merge. The strategies are:

    • MOST_TRUSTED_SOURCE — the value from the source system with the highest trust score (Step 6).
    • MOST_RECENT — the freshest value by the entity's date column.
    • MOST_COMPLETE — the record with the fewest empty attributes wins.
    • LONGEST_VALUE — the longest non‑empty string.
    • MOST_FREQUENT — the value the most contributing records agree on.
    • CUSTOM — your own expression.

    For our example: email MOST_RECENT, customer_number MOST_TRUSTED_SOURCE, address_line1 LONGEST_VALUE. If you want billing's address to win, raise Billing's trust score and use MOST_TRUSTED_SOURCE — the strategy reads trust, it does not name a system directly. 4. Review conflicts. Where contributing records disagree and the strategy cannot settle it, the conflict is recorded and routed to a steward as a survivorship conflict in My Work. Run the deterministic Survivorship Advisor for proposals. 5. Golden Fields. On the Golden Fields sub‑tab, confirm which attributes are published onto the golden record and how they are assembled. 6. Save the rulesets.

▶ The platform now knows how to collapse duplicates and survive the best value for every field.

Tip — strict pipeline mode. For production models an Admin can turn on strict pipeline mode on the model (Deployment Models). It blocks two things: Survive refuses to run without a recorded match run, and Publish refuses without active DQ rules and with any open CRITICAL exception. An override is possible and is written to the audit log.

Sensitivity reminder. Because you classified fields in Step 4, masking applies automatically from here on: classified values are redacted before the response leaves the API, so grids, reports and their CSV exports all inherit the redaction, and Restricted records are hidden entirely from readers without clearance. Grant clearances — scoped to a domain, entity or record, with an expiry — in Administration → Security → Data Access. Two deliberate exceptions: pipelines and jobs are not masked, because match and survivorship need real values; and tenant Admins and superusers see everything unmasked without a grant, unless that default is turned off.

Step 12 — Publish and review golden records

Where: Mastering → Steward → Golden Records · Trace → Pipeline / Lineage, Record Timeline · Integrate → Write‑Back, Real‑time API Role: Steward / Data Owner / Admin

  1. Run the pipeline. Run Match, then Survive, then Publish — from the rulesets, from Jobs & Runs, or as an execution package. Publish promotes the survived rows into the governed golden master.
  2. Browse. Open Mastering → Golden Records and look at the mastered Customer records. Each carries a confidence score built from evidence, a publish line showing whether the golden definition has drifted since the last publish, and a population badge.
  3. Review the merges. Work the pairs the rules sent to REVIEW — confirm or reject each merge. Confirmed merges can later be unmerged; a record that matched nothing forms a cluster of one, which is normal and not an error.
  4. Inspect a record. Open one and read its cross‑reference (xref) — every source record that contributed, field by field — plus the raw source value where standardization changed it ("was: …"), sample values, record‑level exceptions, and the Record Inspector overlay that puts cluster members, related records and exceptions in one place. Right‑click a golden row for: view exceptions · open record · trace · lineage web · sample values · filter by this value · copy golden key.
  5. (Optional) Trace the pipeline. Open Pipeline / Lineage for the entity's whole stage board — row counts per stage, run states, stale‑stage flags — and the lineage web for a single record.
  6. (Optional) Walk the relationships. Open Analytics → Consume → GR Explorer. It shows the domain‑to‑domain relationship strip, a governed grid for the focused entity, and one tab per relationship rendering the related golden rows resolved through the relationship's FK columns. Click a related row to pivot onto it — the breadcrumb keeps your trail (Customer ▸ Order ▸ …). Read‑only.
  7. (Optional) See the history. Open Mastering → Record Timeline for bi‑temporal, effective‑dated history: what the record looked like as of a date, and what we knew about it at a point in time. Golden records are superseded, never deleted, so the trail is complete.
  8. (Optional) Author a record by hand. Mastering → Author Records creates a golden record directly in the hub through a schema‑driven form validated against the entity's own DQ rules. It is stamped MANUAL provenance and can be routed through an approval workflow. Steward, Data Owner or Admin only.

▶ You have trusted, de‑duplicated golden Customer records with full lineage and history. The master data is live.

Note — governance and RACI. With the review bypass off, a governed change routes through Governance → Change Requests for review and approval. At the moment you raise it, the platform resolves the RACI parties from the catalog: Consulted parties are listed on the request, Informed parties are notified, and a RACI snapshot is written onto the request as an audit fact — it is what was true when you raised it, not a live view. Any name on the Informed list that matches no active user is reported back to you by name as not notified, so a silent gap does not stay silent. Only Accountable and Responsible inherit from a governing glossary term.

Note — write‑back writes a script by default. Mastering → Write‑Back works build → preview → impact → per‑item approve/reject → apply → verify → rollback. The default apply mode is SCRIPT: the platform generates an idempotent, drift‑guarded UPDATE script for a human to run against the source. It does not touch the source itself unless you deliberately choose DIRECT (platform‑executed guarded updates in chunked transactions with before‑images for rollback) or PROC. And write‑back is not available on an Oracle hub at all — the runner returns HTTP 501. Ports exist for SQL Server, PostgreSQL and MySQL only.

Note — the Real‑time API decides, it does not master. Mastering → Real‑time API scores an inbound record against the published golden master using the entity's active ruleset and returns ranked candidates with an AUTO_MERGE / REVIEW / NO_MATCH decision, using the same scoring engine as the batch runner so the decisions agree. It also serves a golden record by entity and key. Nothing on that path creates, merges or updates a golden record: mastering is the batch MATCH → SURVIVE → PUBLISH pipeline, and the API serves what that pipeline last published. Inbound events are queued durably and processed on an explicit call, not streamed. A synchronous match loads at most 5,000 candidate rows.

Note — the runners refuse rather than truncate. Survive and Publish stop with a loud error past their configured row caps instead of silently processing part of your data. A large publish escalates itself to a background job past the async row threshold.

Step 13 — Build the report

Where: Analytics → Build → Report Studio · Consume → Report Center, Dashboards · Operations → Pipeline Health Role: Analyst / Steward / Data Owner / Admin

Now turn the mastered domain into something people read.

  1. Open Analytics → Report Studio.
  2. Create a report and choose your data source — your Customer golden records, or any pipeline stage, or a related entity.
  3. Add columns, then group, filter and sort (customers by country, duplicates merged, quality score by source).
  4. Use the expression language for calculated fields, and add drill‑through where you want detail on click.
  5. Preview, then Save/Publish. A published report opens for everyone else in the Report Viewer.
  6. Put it in the gallery. Open Analytics → Report Center — the published gallery of reports and dashboards. This is where a business reader goes; they never need Report Studio. A brand‑new install shows an empty gallery until report definitions exist.
  7. (Optional) Open Analytics → Dashboards, create a dashboard in the Dashboard Builder, and pin your report plus KPI tiles for an at‑a‑glance view.
  8. Confirm the pipeline. Open Analytics → Pipeline Health for the end‑to‑end view — source‑to‑target mapping unified from your field mappings and attribute sources, and a baseline‑versus‑post‑MDM quality comparison that shows what mastering actually bought you.

▶ Done. You've gone from an empty model to a governed, mastered Customer domain with a published report and a healthy pipeline — the full DESIGN → MAP → GOVERN → TRUST journey.

Note — masking in reports. Sensitivity masking is applied to reports built on entity‑stage sources. A report built directly on a raw or intermediate stage source does not inherit that mask — choose the entity stage when the report will be shared widely.

Note — source‑to‑target mapping needs its inputs. Pipeline Health's STTM view is built from registered field mappings and attribute sources (Step 4, sub‑step 5). Without them the panel is empty, and that is a missing input, not a fault.

Quick reference — the whole flow

# Stage Hub → Group → Screen You produce
0 Bootstrap Server — migrate, seed A platform that can hold a model
1 Prepare Header · Administration → Platform → Deployment Models An active, checked‑out model
2 Domain Modelling Studio → Design → Domains & Entities → Domains The domain
3 Entities Modelling Studio → Design → Domains & Entities → Entities Master objects
4 Dictionary Modelling Studio → Document → Data Dictionary Typed, classified attributes
5 Relate Modelling Studio → Design → Data Modelling · Business Glossary · Catalog Relationships + definitions
6 Sources Integration Hub → Configure → Sources & Connections Tested connections
7 Map Integration Hub → Configure → Mapping Designer Source→model mapping sets
8 Standardize Integration Hub → Configure → Standardization Cleansing cascades
9 Ingest Integration Hub → Operate → Jobs & Runs · Orchestration Staged data
10 Quality Quality → Data Profiling · DQ Rules · Data Quality · Exceptions Quality score + worked exceptions
11 Master rules Mastering → Configure → Mastering Rules Match + survivorship + golden fields
12 Golden records Mastering → Steward → Golden Records · Pipeline / Lineage Trusted records + lineage
12+ Explore Analytics → GR Explorer · Mastering → Record Timeline Relationship walk + history
13 Report Analytics → Build → Report Studio · Consume → Report Center · Operations → Pipeline Health Published report

Before‑you‑begin checklist

If a step doesn't behave