Understanding the Role of Change Requests in MDG Governance
Introduces what a Change Request is in SAP MDG, why it exists, and how it enables controlled, auditable master data changes across create, change, and mark-for-deletion scenarios.
Explanation
In SAP Master Data Governance, a Change Request (CR) is the transactional container that wraps every proposed create, change, or deletion of governed master data (such as business partner, material, or custom domain objects) so that nothing is written directly to the active master data table without going through review, validation, and approval steps. This matters because master data errors are expensive to fix once they propagate to finance, procurement, or sales documents; MDG's governance model is built specifically to intercept bad or unauthorized changes before they become 'active' data usable in other processes. Conceptually, a CR is not just a workflow wrapper. It is a business object instance built on the Business Object Processing Framework (BOPF) that holds staged (inactive) data alongside the current active data. When a data steward or requester enters changes, those changes are recorded against the CR's staging area, not the active area. Only when the CR completes its lifecycle successfully (passes validations, duplicate checks if configured, and required approval steps) does the system activate the data, copying it from staging into the active area which is then visible to consuming applications and, where configured, replicated to connected systems. Each CR is associated with a Change Request Type, which is configuration that determines: which business object/entity types can be processed, which change type is allowed (create, change, delete, or a combination), what workflow template governs approval routing, which processor tabs and UI configuration are shown to users, and what business activities and field-level authorizations apply. Without a properly configured CR type, users cannot even initiate the intended kind of change, so understanding CR types is foundational before touching workflow or validation configuration. The CR lifecycle generally moves through statuses such as 'in process', 'to be approved' (or similar review status), 'approved', and 'completed', with 'rejected' or 'withdrawn' as exit paths. Status is not simply a UI label; it drives which validations run, whether the record is locked from other CRs, and whether the workflow step is currently waiting on an agent. Locking matters in real projects: while a governed object instance is inside an open CR, MDG typically prevents other users from opening a conflicting CR for the same object, which avoids two people editing the same material or business partner simultaneously and causing a merge conflict at activation. From a business perspective, CRs give organizations an audit trail: who requested a change, who approved it, what the data looked like before and after, and when it became active. This is valuable for compliance, especially in regulated industries where master data changes (like vendor bank details) require segregation of duties between requester and approver. A beginner should internalize that MDG's value proposition is largely delivered through this CR-and-workflow mechanism, not through validations alone; validations and duplicate checks are quality gates that plug into the CR process, but the CR itself is the vehicle. It is also important to distinguish deployment contexts early. In S/4HANA on-premise and private cloud, CR configuration is highly flexible through IMG customizing, and process modeling is done with tools like the CR type and workflow configuration transactions. In S/4HANA Public Cloud editions of MDG-style governance, configuration options are typically more restricted to predefined, SAP-delivered scenarios with limited extensibility, so architects should not assume identical flexibility across editions. Where uncertain about specific public cloud restrictions, treat them as scenario-dependent and verify against the current release scope rather than assuming parity with on-premise.
Real project scenario
A consumer goods company implementing MDG for material master governance found that plant buyers were directly changing purchasing views in the ERP backend, causing inconsistent valuation classes across plants. The governance team introduced a 'Material Change' CR type restricted to changes on purchasing and accounting views, routed through a two-step workflow: a regional data steward review, then a finance approval step for valuation-relevant fields. Buyers could still request changes through a simplified UI, but nothing reached the active material master without passing through the CR lifecycle, giving finance visibility and control they previously lacked.
Common mistakes
• Assuming a Change Request is just a UI wrapper for a workflow task rather than a staging container tied to a BOPF-based object model • Creating a single generic CR type for all change scenarios instead of separating create, change, and deletion flows, which complicates validation and workflow logic later • Not accounting for object locking behavior, leading to confusion when a second user cannot open a CR for a record already in process • Assuming CR configuration flexibility is identical across on-premise, private cloud, and public cloud editions of MDG • Overlooking that data only becomes active and consumable by other systems after the CR completes, not at initial data entry
Best practices
• Design CR types around clear business scenarios (create, change, mark-for-deletion) rather than one catch-all type • Document which fields and business objects each CR type governs so stewards and approvers understand scope • Educate business users early that data is not 'live' until CR completion, to avoid confusion about why a change is not yet visible • Confirm governance flexibility and CR type restrictions specific to your deployment edition before designing complex scenarios
Interview angle
Interviewers commonly ask candidates to explain the difference between staged and active data in MDG and why that separation exists; a strong answer connects it directly to the Change Request as the mechanism enforcing that separation, and explains the business risk (unreviewed data reaching downstream systems) that the design mitigates.