SAP Change Requests Tutorial (Part 1)

In SAP MDG, a Change Request (CR) is the mandatory container object through which almost all governed master data changes flow. Unlike a classic transactional system where a user might directly edit a customer or material record in a table, MDG deliberately blocks direct changes to active, consolidated master data. Instead, every create, change, mark-for-deletion, or (in some models) delete operation on a governed entity must be proposed inside a Change Request, which then moves through a defined workflow before the data is written to the active area and, where configured, replicated to connected systems.

Why does this matter for a project team? Master data errors are expensive: a wrong tax classification, an incorrect vendor bank detail, or a duplicate business partner can cause payment errors, compliance issues, or reporting inconsistencies across ERP, CRM, and analytics systems. The CR mechanism exists to insert a controlled checkpoint between 'someone wants to change data' and 'the data is actually changed everywhere.' That checkpoint provides three things: (1) a workflow-driven approval chain so the right people review sensitive changes, (2) validation and derivation logic that runs at defined points so bad data is caught early, and (3) a complete audit trail showing who requested what, who approved it, and when it became active.

Structurally, a CR is created against a CR type, which is configured to work with one or more governance scope entities (for example Business Partner, Customer, Supplier, Material, or a custom governed object depending on the domain being governed). When a requester starts a CR, they choose (or the system defaults) a CR type, and the system opens a corresponding UI where the requester enters or changes attribute values. Internally, the proposed values are held in a staging area separate from the active master data; the active data is untouched until the CR completes successfully. This separation is what allows the requester to save a CR in draft, come back later, or have it rejected without ever having touched production-consumable data.

Every CR has a status (such as in process, in approval, completed, or rejected, with exact status names depending on configuration) and moves along a workflow that was defined for its CR type. Even a 'single-level' governance process, where only the requester interacts with the system, technically still uses a CR and a (often very short) workflow, because the CR is what holds staging data, validation results, and history. This is a key beginner point: even simple, low-risk changes are not exempt from the CR concept; only the number of workflow steps and approvers varies.

From an S/4HANA perspective, the concept is consistent whether you are on-premise, private cloud, or public cloud, but the amount of pre-delivered configuration you can change differs. On-premise and private cloud environments generally allow more customization of CR types, workflow steps, and data models. Public cloud editions of MDG-related capabilities typically expose pre-configured governance scenarios with more limited extensibility, so project teams should not assume every knob seen in an on-premise system is adjustable in a public cloud tenant. A consultant new to MDG should first learn to recognize a CR in the UI (its ID, type, status, and workflow log) before moving into configuration details, because troubleshooting always starts with asking 'which CR is this data stuck in, and what step is it at.'

A retail company implementing MDG for material master governance found that store managers were used to editing materials directly in the legacy system. During UAT, several managers were confused why they could not simply change a price group field on the material record. The consulting team ran a short enablement session showing that every change, including a single field like price group, must go through a Change Request, even if that CR type was configured with only one approval step. This resolved the confusion and also surfaced a real requirement: the client wanted certain low-risk fields to skip a second approver, which led to defining a lightweight CR type specifically for minor attribute changes.

• Assuming a 'simple' change can bypass the CR mechanism entirely instead of using a lightweight CR type with minimal steps.
• Confusing the staging (proposed) data shown inside an open CR with the active, already-governed master data.
• Not checking the CR status and workflow log first when a user reports 'my change did not save,' leading to wasted troubleshooting time.
• Expecting the same CR type configuration options to be available in a public cloud tenant as in an on-premise system.
• Treating CR terminology as one-size-fits-all across every governed domain without confirming which entity types a given CR type actually supports.

• Always identify the CR type and current workflow step before diagnosing a reported data issue.
• Educate business users early that all governed changes, however minor, go through a CR, to avoid adoption friction.
• Keep a clear mapping of which CR types apply to which governed entities so support staff are not guessing.
• Distinguish clearly in documentation and training between staging (in-process) data and active (published) data.
• Confirm with the platform team whether the deployment is on-premise, private cloud, or public cloud before promising configuration changes to CR behavior.

Interviewers commonly ask candidates to explain, in plain language, why MDG does not allow direct table-level changes to master data and what role the Change Request plays in that control. A strong answer distinguishes staging data from active data, mentions workflow and audit trail as the two main benefits, and acknowledges that even single-step processes still use a CR. Candidates should avoid vague answers like 'it just approves changes' and instead show they understand the separation of proposed versus active data.