MDM on Product Documentation

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

Master Data Management helps you move data from one leading company into other companies in a structured way, define clear rules for that transfer, and review differences in a targeted manner. The module is especially useful when several companies work with the same master data and changes should not be maintained separately in every company.

Typical use case

One company maintains certain master data centrally first. This data should then also be available in other companies. At the same time, not everything should be transferred without review. MDM helps you decide which data is transferred, which exceptions apply, and how you can review deviations later.

Glossary and roles

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

This glossary consolidates the most important terms and roles of MDM for the first entry into the solution. It helps users read and apply relations, rules, and review steps with one shared business understanding.

Business value

Standardizes the core MDM terminology across business teams, master-data maintenance, and review work.
Makes communication easier between users, business owners, and administrators.
Reduces misunderstandings around relations, DSR, substitutions, and consistency checks.

Content focus

Core terms

Term	Meaning	Typical context
Source company	Company from which business-relevant data is read or compared with the target context.	Data origin, review start, reference context
Target company	Company in which data arrives, is checked, or is evaluated from a business perspective.	Data receipt, comparison, correction
MDM relation	Central business mapping between tables, companies, and processing rules.	Relation list, relation card
DSR	Abbreviation used for Selected Record Distribution and the business term for controlled record distribution in MDM.	Distribution matrix, DSR page, relation maintenance
DSR filter	Rule that excludes records from distribution for all or selected target companies.	Distribution filters, distribution matrix
Relation structure	Structured representation of which fields, levels, or relationships belong to one relation.	Relation Structure, field logic
Dependency	Rule that describes when a value or record depends on other information.	Dependency Lines, control rules
Exclusion	Rule that deliberately excludes specific fields or situations from processing.	Relation Exclusions, exceptions
Substitution	Replacement or derivation of a target value based on defined rules.	Substitutions, field-value control
Consistency check	Review that verifies whether records or field values between source and target contexts match the expected state.	Consistency Check, review results
Review entry	Documented result of a relation review or consistency check.	Check Entries, follow-up
MDM start area	Central entry point for working with relations, activities, and follow-up actions.	Profile, daily entry

Roles and permissions

Role	Typical task
MDM - Read	Read MDM content, understand results, and get oriented
MDM - User	Use relations, rules, and operational MDM functions in day-to-day work
MDM - Administrator	Own the setup, maintenance, release, and business control of MDM
MDM responsible user	Profile that uses the central MDM start area as the entry point for activities and insights

Core logic between relation, rule, and review

The MDM relation is the business core object. Based on that, relation structure, dependencies, exclusions, and substitutions define the expected data behavior. Consistency checks then show whether the result in the target context matches the defined frame or whether follow-up work is required.

Setup

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

This page describes how to establish the baseline for MDM. The sequence is intentional: first define companies and defaults, then build relations, and only after that use rules and reviews in a reliable way.

Prerequisites

MDM is installed in the environment and the responsible users work with an appropriate MDM profile.
It is clear from a business perspective which companies should act as source and target companies in MDM.
Ownership for relation maintenance, release, and follow-up work is aligned between business teams and administration.

Recommended sequence

Select the managed companies and define the default source context.
Review central MDM settings such as routing template defaults, background processing, and the active MDM version.
Create the first MDM relations for the relevant tables and assign source and target companies.
Decide per relation whether Selected Record Distribution with DSR should be used and prepare the related distribution behavior.
Add dependencies, exclusions, DSR filters, and substitutions where business-specific control is required.
Review the relation, move it in a controlled way to Released, and run the first consistency checks.

Setup components

Define companies and the default context

The MDM Setup Wizard starts with the selection of companies that should be configured for MDM. In this step, decide which companies are managed in the module and from which default source company new relations are typically created.

Master data and relation maintenance

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

This page describes the recurring maintenance of MDM master data and relations. The focus is on relations, company assignments, dependencies, exclusions, DSR filters, substitutions, and the preparation needed for later consistency checks.

Business value

Makes the business maintenance of relations and rule sets understandable as reusable master data.
Supports a consistent mapping between source and target companies.
Helps teams prepare controlled deviation handling through rules, DSR, and review logic.

Content focus

Relations as the central maintenance object

The MDM relation is the leading object for maintaining the business data relationship. It combines table context, routing rule, distribution behavior, status, and the related company assignments in one shared maintenance context.

DSR and Distribution Matrix

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

This page is written for responsible business users who steer and review distribution decisions in MDM. Within MDM, DSR is used as the term for Selected Record Distribution. It explains how DSR filters and the distribution matrix work together so that you can define and review, in a traceable way, which records are distributed to which target companies for released relations.

Business value

Makes distribution decisions transparent and reviewable per relation and target company.
Reduces manual follow-up work because you can maintain business exclusion rules centrally through DSR filters.
Supports target-company-specific rule maintenance without rebuilding the entire relation.
Helps teams re-evaluate existing data in a controlled way after a filter change and align the result with business stakeholders.

Focus

DSR as a control layer for record distribution

DSR adds an extra decision layer for individual records on top of the MDM relation. When record distribution is selected for a relation and the relation is released, MDM evaluates incoming records against the maintained DSR filters and derives the initial distribution decision from that result. For responsible business users, this is the central control point for deciding which records should reach target companies productively and which should remain excluded by design.

Process catalog

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

This process catalog describes the key work procedures in MDM from the perspective of responsible business users. The focus is on creating and releasing relations, handling controlled changes, steering DSR filters from a business perspective, working with substitutions, and running consistency checks.

Context

The functional baseline for these processes is described on the Setup and Master data and relation maintenance pages.
The processes target users who maintain relations, release changes, control DSR filters and substitutions, or evaluate review results.

Prerequisites

Source and target companies, routing defaults, and initial relations are configured in MDM.
The involved users have the permissions required to work with relations, DSR filters, substitutions, and consistency checks.
The business-relevant tables and rules are aligned before the process starts.

Process catalog

Process REL-01 - Create and release a relation A new relation is prepared, reviewed, and released for productive use. +

Start by selecting the business-relevant table and defining between which source and target companies the relation should apply.
Use this workflow whenever an additional business-relevant table should become a permanent part of the existing distribution and review logic.
You are working in the relation setup or relation maintenance page. There you see the table, involved companies, and the main control fields.
Add the routing rule, distribution logic, and required rule components such as dependencies, exclusions, and substitutions.
Decide whether the relation is already complete enough for productive use or whether business rules are still missing.
Review the relation with the available review function before changing the status.
Release the relation only after the structure and rules are complete.
Use release without update only if no retroactive update should be triggered for changes made while the relation was in maintenance status.
The visible result is a released relation that can be used for data transfer and review.

Process REL-02 - Change a released relation in a controlled way Released relations are reopened only when needed, adjusted, and released again. +

Reset a released relation to an editable state only when business-relevant changes are actually required.
This workflow is typical when field logic, target-company assignments, or the handling of exclusions and substitutions has changed from a business perspective.
You are in the existing relation and can see its current processing state.
Maintain the adjustments while the relation is in maintenance status so that source and target contexts remain controlled during editing.
Be aware that changes to source or target data can be restricted while the relation is not released.
Review the relation again after the update and release it once the changes are complete.
The visible result is a released relation with traceable changes.

Process REL-03 - Identify missing or related relations Support functions help complete the relation landscape in a consistent way. +

Use the missing-relations suggestion function to identify relations that are missing for business-related tables.
Use this workflow also when business teams suspect new table relationships and you first need to clarify whether a relation is actually missing.
You see a proposal list with additional possible relations.
Use related-relation suggestions when dependencies must be analyzed across several table levels.
Do not adopt suggested relations blindly; review the business value and ownership first.
Refresh field-level relation information when the technical basis for additional rules needs to be sharpened.
The visible result is a clearer decision about which additional relations are really needed.

Process DSR-01 - Maintain DSR filters and re-evaluate existing data Responsible users define exclusion rules per relation and decide how filter changes are applied to records that already exist. +

Open the distribution matrix from a released relation or directly from the central MDM start area when you need to review or adjust distribution decisions from a business perspective.
You see the records of the selected relation and the decision per target company.
From there, open the distribution filters and maintain new filters only in the context of the affected relation table.
Decide explicitly whether a filter should apply to all target companies or only to one specific target company.
After each change, review the distribution matrix to confirm that the expected records are excluded or distributed and that the decision source matches the intended business rule.
Use the function that applies DSR filters to existing data when the new filter logic should also be applied to records that already exist.
Decide consciously whether only default and automatically set decisions should be updated or whether manual decisions may also be overwritten.
Align business-critical changes with the affected teams before running a mass update so that exceptions and special cases are not removed unintentionally.
The visible result is an updated distribution matrix that shows the new decisions.

Process SUB-01 - Maintain substitutions and distribute changes Substitutions control derived target values and can be propagated to additional companies. +

Open substitutions either in the context of a relation or directly from the central substitutions page.
You see the affected fields, target values, and open changes.
Define which target values should be replaced or derived when source and target contexts differ from a business perspective.
Review open substitution changes regularly so that pending delta updates remain visible.
Use Copy Substitutions when existing substitution logic should be transferred to additional companies in a controlled way.
Treat this workflow not only as rule maintenance, but also as the required follow-up processing for already affected target contexts.
The visible result is a clear view of adjusted target values and remaining follow-up work.

Process CHK-01 - Check consistency for records and field values Consistency checks show whether target data matches the expected state. +

Open the relevant consistency check with the source company, target company, and table context you want to review.
You see the table, company context, and later the resulting findings.
Start either a record-based check or a field-based check depending on what you need to analyze.
Evaluate the review entries together with the underlying relations and rules.
If deviations appear, also assess whether the cause lies in missing relations, incomplete rules, open substitution changes, or in the source data itself.
Use the results as the basis for follow-up work, renewed release, or the completion of missing rule components.
The visible result is a traceable list of deviations and follow-up work.

Result

The key MDM processes for relations, DSR, substitutions, and consistency checks are described in a traceable sequence.
Relations, controlled changes, substitutions, and consistency checks are classified as connected workflows.
The page now covers the most important application scenarios directly inside the relevant process context.

Work aids for daily work

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

This page bundles practical guardrails for recurring decisions in daily MDM work. It is aimed at users who release relations, evaluate review results, follow up substitution changes, or want to structure daily maintenance tasks more efficiently.

Business value

Shortens the daily classification of common MDM decisions.
Supports a consistent assessment of releases, review errors, and follow-up work.
Makes recurring control points for relations, DSR, substitutions, and field views more transparent.
Complements process and FAQ pages with concrete orientation for everyday work.

Focus

Decision aid for status actions

Not every status action serves the same purpose. Releasing a relation is the standard path after a complete review, reopening brings a relation back into a controlled editable state, and release without update remains a deliberate exception for cases without retroactive redistribution.

FAQ

Mon, 01 Jan 0001 00:00:00 +0000

FAQ Why can’t I edit a released relation directly? Released relations are intentionally protected so that productive rules are not changed without control. +

Released relations form the productive rule base in MDM and should therefore not be changed unnoticed. When a business rule has to be adjusted, the relation is brought back into an editable status and released again only after another review. For the broader context, see the process catalog.

FAQ When is release without update the right business choice? This action is intended only for deliberately limited changes and should not be the default release path. +

Release without update is appropriate when a relation should be released again without retroactively redistributing already changed records to the target companies. This can be acceptable for clearly scoped rule adjustments, but it should be a deliberate decision because otherwise open business changes will not be carried forward in the target context.

FAQ Why are there still open tasks after substitution changes? Substitutions first change the rule set; the actual follow-up processing can still require an update. +

Changed substitutions do not automatically update all already affected records. Open entries in the change log and a possible update indicate that the business rule has been adjusted, but the operational follow-up processing is still pending. The practical classification is also covered on the work aids for daily work page.

FAQ When should I apply DSR filters to existing data? This action is useful when changed DSR rules should apply not only to new records, but also to records that already exist. +

Use this action when changed DSR logic should also be rolled out to records that already exist. The critical decision is whether only default and automatic decisions should be updated or whether manual decisions may also be overwritten. The business classification of this action is explained on the DSR and Distribution Matrix page.

FAQ What do errors in consistency checks actually mean? Check errors show a deviation between the expected and actual target state, not automatically a technical defect. +

At first, a consistency error only means that MDM found a different state in the target context than the one expected from the relation and rule set. The cause can be a missing relation, incomplete rules, an intentional business deviation, or actually incorrect data. Because of that, review entries should always be assessed together with the relation, the source and target company, and the concrete field context.

FAQ Why doesn’t the missing-relations suggestion always provide usable proposals? Suggestions depend on the existing relation landscape and the business relationship between tables. +

The suggestion functions can only derive relationships that are meaningfully visible from the current table and relation context. If the base relations are too narrow, incomplete, or not yet clearly scoped from a business perspective, the proposal space stays limited as well. Review the existing setup first on the master data and relation maintenance page.

FAQ How do I narrow the field view down to the really relevant information? Field views help distinguish between the full table structure and the fields that are actively used for synchronization. +

In daily review work, not every available field is relevant. Views such as active fields and all fields help users focus either on the actually synchronized fields or on the full table structure. This is especially useful when review results or rule changes have to be classified from a business perspective.