MDM Master Entities

Master entities are governed golden records for real-world objects. Each master entity has a stable ID, an entity type, canonical attributes, lineage, status, version, and source aliases.

Use this workspace to inspect identity quality before the data is used by fusion, AI Agent, Inspector, BI, or reporting workflows.

Before you start

Confirm:

• dfs:read access to view entity types and records;
• dfs:write access if you need to add or re-point aliases;
• dfs:delete access only for structural actions such as merge or split;
• the entity type you are reviewing;
• the source systems that should contribute aliases;
• the steward responsible for identity decisions.

Open Master Entities

Go to:

Data Integration > DFS Pro > Master Entities

The page shows entity types on the left and golden records on the right. Select a row to open the detail drawer.

Entity review flow

Use this flow before a master entity set is handed off to fusion tasks, Inspector, AI Agent workflows, or reports.

Read the list

Column	Meaning
Entity	Short form of the stable master entity ID.
Canonical	Preview of canonical attributes.
Status	Whether the record is active or merged.
Version	Version of the canonical record.

If a type has no records, confirm that the entity type exists for the tenant and that resolver or import work has created records for that type.

Inspect a golden record

Open a record and review:

• full entity ID;
• status and version;
• effective date range;
• canonical attributes;
• active and historical aliases;
• match method and confidence;
• lineage.

Canonical attributes should be stable enough for downstream users to recognize the object. Keep them focused on the fields that identify and explain the record.

Entity quality checks

Review a sample from each source system and each high-impact asset class:

Check	What good looks like
Stable identity	The record represents one real-world object across its lifecycle.
Alias coverage	Expected source systems have active aliases or documented gaps.
Canonical clarity	Name, class, location, and status help users recognize the object.
Lineage completeness	Users can see which sources contributed the record and when.
Steward decisions	Fuzzy approvals, rejections, merges, splits, and re-points are explainable.
Downstream readiness	Dependent datasets and workflows know which entity ID to use.

For production handoff, base approval on sampled evidence from records that affect reporting, work orders, AI Agent answers, or operational dashboards, not on record counts alone.

Validate lineage

Lineage explains where the canonical record came from. Check:

• which source systems contributed attributes;
• whether the source IDs are still active aliases;
• whether the steward has enough source evidence to approve downstream use;
• whether recent merges, splits, or re-points changed the identity.

Handoff example

A concise handoff note can use this shape:

Entity type: equipment
Active records: 1,248
Source systems: BMS, CMMS, Inspection
Open candidate queue: 37 pending, 12 rejected this run
Known gaps: 18 BMS tags without maintainable-object alias
Recent structural changes: 4 merges, 1 split, 9 re-points
Downstream refresh: inspection fusion rerun; BI refresh pending
Owner: facility data steward group

Keep the handoff factual. It should help the next team decide whether to use the identity set, continue review, or rerun downstream workflows.

Good handoff output

When handing off a master entity set, include:

• entity type;
• number of active records;
• source systems included;
• unresolved or rejected candidate count;
• known alias gaps;
• whether merge/split actions occurred;
• downstream datasets or workflows that rely on the identity.

Common issues

Symptom	Likely cause	Fix
A real-world object appears twice	Duplicate golden records exist.	Compare aliases and lineage, then use merge only if the records are the same object.
One record contains aliases from different objects	Over-clustered identity.	Use split to peel selected aliases into a new record.
A source ID points to the wrong record	Incorrect crosswalk.	Re-point the alias after checking source evidence.
Canonical attributes are sparse	Source records are missing fields or survivorship rules need review.	Review source mappings and update attributes through the approved workflow.
A merged record still appears in downstream output	The downstream workflow is reading historical facts.	Confirm the workflow resolves to the current entity ID or reruns with updated identity.

Next step

Use Cross-Source Aliases to understand how source-system IDs map to master entities.