MDG Architecture Map: Data Model, Change Requests, Workflow, and Replication Flow
Walk through the end-to-end MDG process flow spanning the governance data model, change request lifecycle, workflow routing, validations, and replication to consuming systems.
Explanation
Once the business case for governance is understood, the next step is understanding how a change request actually moves through the system from creation to distribution. This lesson maps the conceptual architecture that underlies every MDG domain (Business Partner, Material, Finance), so that when you study each domain's child topics in depth, you already recognize the recurring building blocks. The governance data model in MDG is layered. There is an active area, which mirrors the structure of the productive business objects (for example, Business Partner tables, Material master tables, or Finance master objects like cost centers and GL accounts). There is also a staging area used while a change request is open; this staging structure typically extends the active structure with additional metadata needed for governance, such as processing status per field or entity, and it is not visible to operational transactions until the change request activates. Between these two areas sits the change request itself, which is the unit of work: it references one or more entities and one or more processing steps, carries a status (such as created, in process, to be approved, approved, or completed), and logs each user action for audit purposes. Workflow is the mechanism that routes a change request through configured process steps. A simple single-level approval might involve just a requester and one approver, while more complex domains like Finance often require multi-step approval (for example, a regional accountant proposes a new cost center, then a controlling lead approves), and Business Partner changes affecting credit limits or payment terms may require an additional finance-specific approval step layered on top of the base master data approval. Agent determination rules decide which user or role receives each workflow step; poorly designed agent rules are one of the most common causes of stalled change requests in production, because a request can sit in an unattended queue if no valid agent is found. Validations and derivations run at defined points in the process, typically when a user saves a step and again before final activation. Validations block progression if a rule fails (for example, a required tax classification is missing), while derivations automatically populate or default certain fields based on other values (for example, deriving a reconciliation account from an account group). Getting the sequence of validations and derivations right matters: derivations generally should run before the validations that depend on their output, and rules should be scoped to the correct entity type and change request type to avoid unintended side effects on unrelated processes. Duplicate checking, where configured, usually runs early, ideally at creation time before a user invests effort filling out a full request, comparing key identifying fields (name, address, tax ID, or similar) against existing active records and flagging likely matches for review rather than automatically blocking creation, since false positives are common and manual judgment is often required. Once a change request completes all required approvals, activation moves the staged data into the active area. In embedded deployment, this active area is typically the same tables consumed directly by transactional processes, so activation effectively makes the data available immediately for daily business use. In hub deployment, or when other systems must also receive the update, a replication step distributes the approved data outward, commonly through standardized interfaces or message-based integration appropriate to the domain and target system, whether that target is another SAP system, a non-SAP system, or a cloud application. Replication monitoring is a critical production support activity: failed replication messages must be identified, root-caused (mapping errors, missing configuration in the target system, network issues), and reprocessed without creating duplicate or inconsistent records downstream. Across deployment models, S/4HANA on-premise and private cloud generally offer the most configuration flexibility for workflow steps, validations, and custom fields, while S/4HANA Cloud Public Edition standardizes much of this configuration and limits custom extensions in line with clean core principles, meaning organizations should expect more configuration-driven, less code-driven governance in that environment. Understanding this end-to-end flow is the necessary foundation before studying the field-level and domain-specific configuration covered in dedicated Business Partner, Material, and Finance governance lessons.
Real project scenario
A retail company implementing MDG for Material master data defines a change request type for new product creation that includes a duplicate check on product description and barcode, a two-step workflow (category manager approval, then finance approval for costing-relevant fields), and automated derivation of the base unit of measure from the product hierarchy. During hypercare, the support team notices several change requests stuck in the finance approval step because the agent determination rule referenced an organizational unit that had been restructured, leaving no valid finance approver assigned; the team corrects the agent rule and manually reassigns the stuck requests.
Common mistakes
• Confusing the staging area with the active area and expecting in-process changes to be visible to transactions before activation • Placing validations before the derivations they depend on, causing false validation failures • Designing overly rigid agent determination rules that break when organizational structures change • Treating duplicate check matches as automatic blocks instead of review prompts, frustrating legitimate business users • Failing to monitor replication failures, allowing golden record and consuming system data to silently drift out of sync
Best practices
• Map out the full change request lifecycle (creation, validation, workflow steps, activation, replication) before configuring any single domain • Keep agent determination rules aligned with current organizational structures and review them after reorganizations • Sequence derivations before dependent validations and document the intended execution order • Configure duplicate check as an advisory step with clear override justification rather than a hard block • Establish replication monitoring with alerting so failed distributions are caught and resolved promptly rather than discovered by end users
Interview angle
A frequent interview question is to describe what happens to master data between change request creation and activation, testing whether the candidate understands the staging versus active area distinction. Another common probe is asking how a stuck workflow item would be diagnosed in production; a solid answer references checking the change request status, reviewing the configured agent determination logic, and confirming whether replication (if applicable) succeeded after activation, rather than jumping to generic troubleshooting.