Why Governed Data Change Requests Matter in MDG
Introduces the business and technical purpose of SAP MDG's change-request-based governance workflow, contrasting direct table maintenance with controlled, auditable data change processes.
Explanation
Master data such as business partners, materials, or finance master records typically feeds multiple downstream processes: order-to-cash, procure-to-pay, financial reporting, and analytics. If master data is created or changed directly in tables or through uncontrolled transactions, errors propagate silently into these processes, causing duplicate vendors, incorrect tax classifications, wrong costing, or broken integrations. SAP Master Data Governance (MDG) addresses this by wrapping every create, change, or mark-for-deletion action in a Change Request (CR), which is a governed unit of work that moves through a defined workflow before the data becomes active in the governance hub or is distributed downstream. At its core, a Change Request bundles one or more governed data objects (for example, a business partner and its related roles) together with the requested field-level changes. Rather than a user directly overwriting a live record, the user works in a staging area. The staged data is validated by business rules and derivation logic, then routed through a workflow that can include steps such as request creation, specialist review, data steward approval, and final activation. Only when the workflow reaches a successful end does the system activate the changes into the active area, from where replication or consolidation processes can propagate the data onward. This pattern exists because master data errors are expensive to unwind after the fact and because many organizations have segregation-of-duties requirements: the person requesting a new vendor should typically not be the same person who approves payment-relevant banking details on that vendor. Workflow-based governance enforces this separation naturally, since each workflow step can be assigned to a different agent or role, and the system records who did what and when, which supports audit and compliance needs. From a beginner's perspective it is important to understand three things distinctly: the governed data model (which entities and attributes are in scope for governance), the Change Request type (which defines what kind of change is being governed, e.g., create vendor, change material), and the workflow attached to that Change Request type (which defines the sequence of processing steps). These three pieces are configured together but conceptually separate: the data model defines what can be changed, the CR type defines how a change is packaged, and the workflow defines who touches it and in what order. In SAP MDG on S/4HANA, this pattern is consistent across supported domains such as business partner, material, finance master data hierarchies, and custom domains built with the Flexible or Central Governance framework. Cloud-ready deployments and SAP Master Data Governance on SAP BTP or public cloud variants may differ in the degree of workflow customization allowed, but the fundamental idea of a staged, workflow-governed change remains the shared principle across editions; exact configurability differs by product and release, so this should be verified against the specific deployment rather than assumed uniform. Understanding this foundational concept is essential before diving into workflow step configuration, rule-based agent determination, or duplicate check integration, because every later governance capability is built as an extension or refinement of this basic staged-change-request lifecycle.
Real project scenario
A retail company implementing SAP MDG for business partner governance found that buyers were creating vendor master records directly and immediately using them for purchase orders, sometimes with incomplete or duplicate tax information. After introducing a Change Request-based workflow requiring a data steward review step before activation, incomplete or duplicate vendor creations were caught before they entered the active vendor master, reducing downstream payment blocks and duplicate vendor cleanup effort.
Common mistakes
• Assuming governance workflow is optional overhead rather than a control point tied to compliance and data quality objectives. • Confusing the governed data model configuration with the Change Request type configuration, leading to CR types that reference the wrong entities. • Expecting identical workflow capabities across all SAP MDG deployment options without verifying edition-specific differences. • Allowing a single business role to both request and approve sensitive changes, defeating the purpose of segregation of duties.
Best practices
• Clearly document which data objects and attributes are in scope for governance versus data maintained outside MDG. • Involve business data owners early when deciding which changes require workflow approval versus automatic activation. • Keep the mental model of data model, CR type, and workflow as three related but distinct configuration layers. • Validate deployment-specific governance capabilities against current product documentation rather than assuming feature parity across editions.
Interview angle
Interviewers often ask candidates to explain, in plain terms, why an organization would introduce a change request and workflow layer instead of allowing direct master data maintenance; a strong answer connects data quality, audit trail, and segregation of duties rather than only describing configuration steps.