SAP MDG Interview Questions

An introduction to the concept of an SAP MDG data model, explaining why it is the backbone of governance for business partner, material, supplier, customer, and custom domains. Deep explanation: In SAP Master Data Governance, the data model is the structural definition of a governance object: the entity types, their attributes, the relationships between entities, and the mapping to the underlying business object (such as Business Partner or Material). Before any change request, workflow, or validation rule can be configured, a data model must exist that tells MDG what the object looks like and how its pieces relate to each other. Why this matters: MDG is not a generic workflow tool bolted onto SAP tables. It is a governance layer that understands the semantic structure of master data. When a consultant configures governance for business partners, the data model already exists as a delivered structure (using the standard Business Partner data model), because business partner governance is deeply integrated with the Business Partner architecture in S/4HANA. For custom objects, or for extending standard objects with additional attributes, you work with the data model layer directly. A data model consists of several building blocks. Entity types represent the main governed objects, such as Business Partner, Material, or a custom object like Cost Center Hierarchy Node. Each entity type has attributes, which map to fields on the underlying database or API structure. Entity types can have relationships to other entity types, such as a Business Partner having Addresses, Bank Details, or Roles as dependent entities. These relationships are important because they determine what data is edited together in a single change request and how the UI presents hierarchical or nested data. The data model also determines how MDG generates or consumes UI configuration. In the standard delivered content for Business Partner, Material, Supplier, and Customer governance, SAP ships a working data model, floorplan UIs, and business rules, so beginners typically work with pre-built structures rather than building models from scratch. Understanding the model, however, is essential because every troubleshooting task, every rule configuration, and every change request behavior traces back to how entities and attributes are defined. From a beginner's perspective, it helps to think of the data model as answering three questions: What object are we governing? What are its parts and sub-parts? And how do those parts relate to the real business object that eventually gets replicated to receiving systems. Without a correct mental model of this structure, governance configuration work such as rule assignment, validation setup, or workflow step configuration becomes guesswork. In S/4HANA, MDG for Business Partner, Customer, and Supplier is tightly coupled to the Business Partner model, meaning many attributes and relationships mirror the BP structure directly. In S/4HANA Cloud Public Edition, the governance capabilities are more constrained and configuration options are reduced compared to on-premise or private cloud, with SAP controlling more of the extensibility surface. This is an important distinction for beginners to internalize early: what is configurable on-premise may not be configurable, or may be configured differently, in the public cloud edition. Recommended practices: • Always confirm whether the object being governed uses a standard delivered data model or requires custom model definition before estimating effort. • Document entity type and relationship structure early in a project so business rule and UI teams share a common understanding. • Clarify deployment target (on-premise, private cloud, public cloud) before promising data model extensibility to stakeholders. • Use available data model review tools or documentation to confirm attribute existence before configuring rules or UI fields referencing it. Common mistakes to challenge: • Assuming the data model is just a UI screen definition rather than the underlying structural and relationship definition. • Trying to add new attributes directly in UI configuration without confirming the attribute exists on the entity type first. • Not distinguishing between entity types, attributes, and relationships when discussing requirements with business analysts. • Assuming all governance domains (Business Partner, Material, custom objects) share identical extensibility rules across deployment options. • Overlooking that public cloud editions typically restrict data model changes compared to on-premise or private cloud. Interview angle: Interviewers often probe whether a candidate understands that MDG governance is built on a structured data model rather than free-form workflow screens. Be ready to explain entity types, attributes, and relationships in plain language, and to describe why standard objects like Business Partner ship with a pre-built model while custom objects require explicit data model definition work.

Understand the business drivers for centralized master data governance and how MDG fits into an S/4HANA landscape spanning Business Partner, Material, and Finance domains. Deep explanation: Organizations running SAP typically accumulate master data across multiple systems: an ERP for finance and logistics, a CRM for customer interactions, and sometimes legacy systems from acquisitions. Without governance, the same customer or material can exist with different codes, inconsistent tax classifications, duplicate vendor records, or mismatched cost center assignments. These inconsistencies cause failed postings, incorrect reporting, compliance exposure, and wasted reconciliation effort. SAP Master Data Governance (MDG) addresses this by centralizing the creation, change, validation, and approval of master data before it reaches operational systems. MDG is built around a few core ideas that recur across every domain it governs: Business Partner, Material, Finance (cost center, profit center, GL account, etc.), and custom objects. First, governance happens through change requests (CRs) rather than direct table updates. A CR bundles one or more entity changes, routes them through a configurable workflow for review and approval, and only activates the data once the required approvals are complete. This creates an auditable trail of who requested what, who approved it, and when it went live. Second, MDG separates staging data from active data. While a change request is in flight, the proposed values live in a staging area; the productive tables are untouched until activation. This means governance does not block ongoing operations, and a rejected or withdrawn request leaves no trace in active data. Third, validations and derivations enforce data quality rules before activation: mandatory field checks, format rules, cross-field consistency (for example, a company code must exist before assigning a reconciliation account), and business rules unique to the organization (for example, payment terms must align with a customer's country group). Fourth, duplicate check functionality helps prevent redundant master records, particularly important for Business Partner and Material where near-duplicate entries (same company, slightly different spelling) are common and costly. Fifth, once approved, MDG can replicate governed data to consuming systems, whether within the same S/4HANA instance, to other SAP systems, or to non-SAP systems, keeping the golden record consistent everywhere it is consumed. Across deployment models this looks different. In SAP S/4HANA on-premise or private cloud, MDG can run as an embedded deployment inside the same S/4HANA system that also processes transactions, or as a hub deployment on a separate system dedicated to governance. Embedded deployment reduces integration complexity because the active area is the same tables the operational processes use, but it requires careful workflow and authorization design so governance does not interfere with daily transaction processing. Hub deployment isolates governance but adds replication complexity because approved data must be distributed to every consuming system, including the S/4HANA system(s) that actually use it. In SAP S/4HANA Cloud Public Edition, governance capabilities are more standardized, more restricted in extensibility, and typically rely on pre-delivered business configuration rather than deep custom development, aligning with the Recommended practices: • Start governance scope small (a critical subset of fields or a single domain) and expand iteratively based on demonstrated value • Assign accountable business data stewards per domain before go-live, not after • Document the change request types and workflow steps clearly so business users understand SLAs for approval turnaround • Align deployment choice (embedded vs hub) with the number and complexity of consuming systems, not just current system landscape • Establish a data quality baseline and remediation plan for existing master data alongside new governance rules Common mistakes to challenge: • Treating MDG as a pure IT project without assigning business data stewards who own approval decisions • Underestimating the effort to design workflow agent determination, leading to change requests stuck with no valid approver • Governing too many fields at once in the first rollout, overwhelming stewards and slowing down urgent business changes • Assuming embedded and hub deployment have identical integration effort; hub deployments require significantly more replication design • Ignoring existing data quality issues, so governance is applied only to new records while historical duplicates remain unresolved Interview angle: Interviewers commonly ask candidates to explain the business justification for MDG versus simply enforcing validations in the operational system directly. A strong answer highlights the separation of staging and active data, the auditable approval trail, cross-system consistency through replication, and the ability to apply consistent rules across multiple source channels rather than duplicating logic in every consuming application. Be ready to contrast embedded

Understand the business problem MDG-F solves, which financial master data objects it typically governs, and how the governance model differs from direct maintenance in FI/CO transactions. Deep explanation: Financial master data such as GL accounts, cost centers, profit centers, and company code assignments underpins every posting, report, and consolidation run in an organization. When multiple people across regions or business units maintain this data directly in FI/CO backend transactions, inconsistencies creep in: duplicate GL accounts with different descriptions, cost centers assigned to the wrong controlling area, profit centers missing required attributes, or company codes configured with mismatched chart of accounts. These inconsistencies cause failed postings, incorrect consolidation, audit findings, and reconciliation effort that finance teams absorb month after month. SAP Master Data Governance for Financial data (commonly called MDG-F) addresses this by introducing a controlled, workflow-driven process for creating and changing financial master data objects instead of allowing free-form maintenance in transactional systems. Instead of a controller directly changing a cost center master record in the backend, they submit a change request. That change request carries the proposed data through validation rules, duplicate checks, and an approval workflow before the change is committed and, where applicable, replicated to connected target systems (ERP/S4HANA financial systems, BW, or other consuming applications). The objects typically governed under Financial MDG include: GL account (chart of accounts data and company-code-specific segments), cost center, cost element, profit center, internal order (in some implementations), and company code or controlling area related master attributes. Each object type has its own data model definition inside MDG, meaning the governance framework knows which fields exist, which are mandatory, and which internal structures (entity types) hold that data. A foundational concept for beginners is the separation between the 'active area' (the system of record where validated, approved master data lives and from which it can be consumed) and the staging/governance area (where change requests are drafted, validated and routed through workflow before activation). Data does not become visible to downstream financial processes until it is activated, and depending on configuration, distributed/replicated to target systems. This staging model is what allows an organization to catch a duplicate cost center or an invalid GL account hierarchy assignment before it ever reaches the general ledger. Another core beginner concept is the governance scope decision: an organization does not have to govern every object end-to-end. It is common to start with a narrower scope, for example GL account creation only, or cost center create/change, and expand the governed object list over time. This phased approach reduces initial rollout risk and lets the finance and IT teams build workflow and validation maturity before governing higher-volume or higher-risk objects like profit centers used in intercompany elimination. Financial MDG can run as a hub deployment (a dedicated governance system separate from the transactional ERP/S4HANA system, replicating governed data outward) or, in S/4HANA, governance capabilities can be positioned closer to or co-deployed with the transactional system depending on the specific product edition and architecture chosen by the customer. The exact deployment option affects how replication is configured and how real-time the governed data appears in the consuming financial system, so this decision is typically made jointly by finance, master data governance, and basis/architecture teams before configuration begins. For a beginner, the practical takeaway is: financial master data governance is not simply a set of authorization restrictions on existing transactions. It is a distinct process layer, with its own data model, request lifecycle, validation logic, and (frequently) workflow approval, that exists specifically to protect the integrity of financial master data before it reaches the general ledger, controlling, or consolidation processes. Recommended practices: • Start governance scope with a small, well-understood object set (for example GL accounts) before expanding to cost centers, profit centers, or company code attributes. • Document clearly which financial master data objects are governed through MDG-F and which remain under direct backend maintenance, to avoid confusion among finance users. • Involve controlling, consolidation, and audit stakeholders early to define mandatory fields and validation intent before technical configuration begins. • Set expectations that governed data becomes usable only after change request activation (and replication, where applicable), not at creation time. • Confirm the deployment approach (hub versus more integrated S/4HANA setup) with architecture teams before committing to a rollout timeline. Common mistakes to challenge: • Assuming MDG-F is only an authorization/security tool rather than a distinct staging

Understand what BRFplus is, why MDG relies on it for validations and derivations, and how it fits into the governance data model and change request runtime flow. Deep explanation: BRFplus is SAP's generic, reusable Business Rule Framework, delivered as part of the ABAP stack and exposed through a dedicated workbench UI as well as APIs. In classic MDG configuration (data modeling, business activities, UI configuration, workflow), BRFplus is the mechanism most commonly used to implement two categories of custom logic: validations (checking that master data meets business rules before it can be activated) and derivations (automatically computing or defaulting field values based on other field values or master data attributes). MDG exposes 'hook' points in its rule-based validation and derivation framework where you assign a BRFplus function as the implementation for a specific entity, usage, and event (for example, checking a field on save, or deriving a value when a segment is created). This means functional consultants and rules specialists can implement significant amounts of governance logic through configuration and rule modeling rather than custom ABAP classes, though ABAP-based Business Add-Ins remain available for logic that BRFplus cannot express cleanly. Architecturally, a BRFplus application is a container that holds functions, rules (decision tables, decision trees, rule sets), expressions (formulas, decision tables, table operations, procedure calls), data objects, and catalogs. A BRFplus function is the callable unit: it has a signature (context/input data objects and result data objects) and a processing structure that determines which rules or expressions execute in what order. When MDG needs to validate or derive data, it invokes the corresponding BRFplus function, typically passing in a context structure that maps to the relevant governance data model entity (for example, a business partner or material change request payload), and BRFplus returns either a result value (for derivation) or a set of messages (for validation, indicating errors, warnings, or informational findings). Runtime integration works within the change request lifecycle. As a user processes a single object or multi-record change request, MDG's rule execution framework calls the assigned BRFplus functions at the configured processing time: for instance, on entering edit mode, on individual field changes, or on triggering a status transition or workflow step. Validation results appear as UI messages tied to the relevant field or entity, and can influence whether a change request can move forward. Derivations write values silently into the working data, which the user can then review before submitting the change request. Because this happens inside the standard MDG UI and workflow engine, well-designed BRFplus rules feel like native application behavior rather than bolt-on logic, which is exactly the design intent: functional teams can adjust business rules by changing rule content in the BRFplus workbench without a full development transport of ABAP code, though changes still typically flow through standard transport management to move between systems safely. Understanding this integration boundary is essential before writing any rule: you need to know the specific entity, usage ID, and event context that MDG configuration expects, because a syntactically correct BRFplus function that doesn't match the expected signature or is not correctly assigned in MDG's validation/derivation configuration will simply never fire, silently, which is one of the most common early troubleshooting scenarios. Recommended practices: • Always simulate and unit test a BRFplus function inside the BRFplus workbench with representative context data before assigning it in MDG. • Keep validation and derivation functions focused on a single clear business rule rather than combining unrelated checks into one function. • Document the entity, usage, and event assignment for every custom BRFplus function so support teams can trace why a rule fires. • Use decision tables for business rules that change frequently (rates, thresholds, mappings) so business users or governance analysts can maintain values without a development request. • Version and transport BRFplus applications through standard transport management and maintain a naming convention that ties functions back to the MDG entity they support. Common mistakes to challenge: • Assuming a BRFplus function will run automatically once created, without correctly assigning it to the specific MDG entity, usage, and event in the validation/derivation configuration. • Building rule logic in BRFplus that duplicates checks already enforced at the data model or domain level, causing conflicting or redundant messages. • Not testing the BRFplus function directly in the BRFplus workbench simulation before wiring it into MDG, making it hard to isolate whether a failure is a rule logic issue or an MDG integration issue. • Overlooking that context data objects passed by MDG may not include every field a consultant assumes is available, leading to null-reference type failures inside expressions. • Treating BRF

Implement a validation rule in BRFplus scoped to the customer entity, using a decision table or rule that checks the country key and applies a regex/format pattern for the VAT field. The rule is attached to the relevant process step (e.g., before activation) and raises an error message if the format doesn't match. Country-specific patterns should be maintained in a BRFplus decision table for easy extension without code changes, and the rule should be tested against edge cases like blank VAT for countries where it's optional.

Configure a key mapping outbound implementation in DRF (or use the Key Mapping app/SOA-based key mapping service) linking the MDG internal ID to the receiving system's local key. The mapping table stores object type, source system, target system, and both key values. For CPI-integrated targets, the mapping is often populated via a confirmation message-back from the receiver after successful load, ensuring keys stay synchronized during hypercare when reprocessing failed messages.

The MDG data model consists of entity types (root and dependent), attributes, relationships between entity types, and mapping to underlying persistence tables (active area and staging area). Root entity types represent the governed object (e.g., Business Partner, Material); dependent entity types capture sub-structures like addresses or roles. Relationships define hierarchy and cardinality. This structure is defined in transaction USMD_MODEL and drives generated UI, workflow, and BRFplus context availability.

The duplicate check service compares new or changed master data (e.g., business partner, customer) against existing records using fuzzy search and similarity scoring to flag potential duplicates before they are created. In HANA-based systems, it uses HANA search or fuzzy search functions and search models built on database views for fast, scalable matching across large data volumes, improving performance versus classic ABAP-based search helps.

Design conditional workflow branching based on whether the financial object change impacts SD-relevant attributes (e.g., account assignment used in pricing procedures or credit control area linkage); route only SD-impacting changes through an additional approval step involving SD/credit stakeholders, while standard financial object changes follow a lighter approval path. Use BRFplus or rule-based agent determination to dynamically evaluate impact and route accordingly, and gate activation so downstream replication only occurs after all required approvals close.

Since DRF only confirms delivery to the outbound channel (often asynchronous), a successful DRF status doesn't guarantee CPI processing succeeded. I'd check CPI's message monitoring for the specific interface, looking at processing time, payload size, and any downstream connection timeouts (e.g., to the receiving system). Likely causes include CPI iFlow timeout settings too low for large payloads, connection pool exhaustion, or downstream system unavailability. Resolution involves adjusting iFlow timeout/retry configuration, implementing batching for large payloads, and setting up alerting correlated between DRF and CPI logs so failures are caught even when DRF shows success.

Investigate by reviewing the consolidation/matching run logs and the survivorship rules that determined which bank detail won, checking BRFplus rule traces and change documents on the merged record. Root cause is often a survivorship rule prioritizing the wrong source system or missing a validation step for sensitive fields like bank data. Prevent recurrence by adding a mandatory manual review step (governance workflow) for bank/payment-relevant fields during consolidation, plus a post-merge validation rule specifically checking bank data consistency before activation.

I'd establish periodic review of replication model filter criteria to prevent scope creep, enforce batch-size and parallel-processing limits documented in a runbook, set up proactive monitoring thresholds on queue depth and processing time, and require performance impact assessments before any new object type or filter is added to production. I'd also mandate load testing for high-volume replication changes before go-live and schedule regular queue health reviews with the basis team.