Master data management process flowchart
Master data management process template for validating requests, matching records, approving changes, publishing identifiers, maintaining attributes and retiring records.
What the master data management process is
Shared customer, supplier, product, location or other reference entities need a lifecycle, not just a create form. This template captures the requested attributes, source and effective date, validates required values, and searches candidate records before anything new is created. An exact duplicate links the requester to the existing master, while a potential match receives steward review to choose a merge, link or genuinely new record. The proposed record includes downstream and control impacts for owner approval before master data operations publish identifiers, mappings and synchronized changes to subscribed applications.
The process continues after publication. Stewards monitor duplicate signals, usage and attribute changes; updates return through validation and approval, while retirement waits for dependency, replacement and retention decisions before deactivation. The data catalog process at /templates/data-catalog-process makes governed assets discoverable but does not replace entity matching or distribution. The lineage process at /templates/data-lineage-documentation-process can show where master identifiers travel, and /templates/data-governance-process can resolve ownership or policy disputes exposed by a request. This chart stays vendor-neutral: matching methods, approval thresholds, survivorship logic and synchronization mechanisms are choices to configure for each entity domain.
What this flowchart covers
In this template
- Create and change request intake with required attributes, reference-value validation, source and effective date
- Candidate search with distinct routes for an exact duplicate, potential match and no-match proposal
- Steward preparation, downstream impact assessment and accountable data owner approval before creation or update
- Controlled publication of identifiers and mappings, application synchronization and distribution reconciliation
- Ongoing change monitoring plus dependency, replacement, retention and approval checks before retirement
When to use this template
- Shared entities are created independently in several applications and duplicates cause reporting, service or transaction errors
- Record changes reach consuming systems without clear stewardship, approval, effective dates or reconciliation
- Teams need an agreed operating flow before configuring matching, workflow and distribution in an MDM platform
- Old records remain active indefinitely because no owner assesses dependencies, replacement identifiers or retirement handling
How it works
Choose the entity boundary
Define which customer, supplier, product, location or other entity types use this process and which system holds the controlled record. Specify required attributes and accepted evidence separately for each domain.
Design matching and treatment rules
Document exact and potential match signals, the search scope, review evidence and who may choose merge, link or create. Add survivorship and alias rules for attributes where sources disagree.
Set approval by impact
Identify the accountable owner and the changes that require explicit approval, including control-sensitive attributes or broad downstream effects. Keep the request, matching evidence and proposed values together for review.
Map publication and reconciliation
List subscribed applications, identifiers, crosswalks, publication timing and failure handling. Define how each consumer confirms receipt so a successful source update is not confused with complete distribution.
Build maintenance and retirement
Route attribute changes back through validation, monitor duplicate and usage signals, and define retirement evidence. Preserve identifiers and aliases needed to interpret history while applying your own retention and access rules.
Frequently asked questions
What are the steps in a master data management process?
Capture and validate the request, search existing records, resolve exact or potential matches, prepare the governed record, assess downstream impacts, obtain owner approval, create or update the master, publish identifiers and mappings, reconcile consumers, monitor changes and duplicates, and assess dependencies before retirement.
Why must matching happen before approval and creation?
Approval of a well-formed request does not prove the entity is new. Searching and reviewing candidates first prevents an approver from authorizing a duplicate, preserves existing identifiers and lets the proposal show whether the correct outcome is link, merge, update or create.
How is MDM different from a data catalog?
MDM controls the identity and lifecycle of shared entity records, including matching, approval and distribution. A catalog describes and helps users discover data assets, terms, owners and usage context. Catalog entries can point to master data, but catalog publication does not perform entity resolution.
When is a master data record safe to retire?
Retire only after owners identify dependent systems and processes, select any replacement record, define downstream behavior, reconcile active uses and decide how identifiers and aliases remain available for historical interpretation under the organization's records practices.
Where this process fits
In most operations this process hands off to Data governance process flowchart (issue to closure).
Comes after
- Data governance process flowchart (issue to closure) — Data governance process template for scoping issues, assigning ownership, assessing cross-domain impact, recording decisions, implementing actions and closing with evidence.