Advanced Business Partner Governance: Architecture, Integration and Production Design (Part 7)

At senior and architect level, Business Partner Governance should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
Why Business Partner Governance Matters and How the Data Model Works: Understand the business case for governing Business Partner master data centrally and how MDG structures BP data using entity types, attributes, and the underlying Business Partner data model.

Change Requests and Workflow for Business Partner Data: Learn how Business Partner change requests are structured, how workflow routes approvals, and how validation and derivation rules interact with the process to protect data quality.

Duplicate Prevention and Data Quality Rules for Business Partner Change Requests: Learn how SAP MDG uses search-based duplicate checks and rule-based validations to prevent low-quality or duplicate Business Partner records from entering a governed change request, and how to interpret and tune these checks in a project.

Why Business Partner Governance Matters in SAP MDG: An introduction to why organizations govern Business Partner data centrally in SAP MDG, the business risks of ungoverned master data, and how MDG's data model, roles, and processes address those risks.

Change Request Types and Workflow for Business Partner Governance: A practical look at how Change Requests are configured and executed for Business Partner governance in SAP MDG, including CR types, entity processing steps, workflow routing, and how approvals move data from staging to active state.

Configuring Change Request Types and Workflow for Business Partner Governance: Learn how change request types, entity types, and workflow templates work together to route Business Partner create/change/mark-for-deletion requests through approval steps in SAP MDG.

Architecture and production criteria

• Always use rule-based or role-based agent determination rather than named-user hardcoding in workflow configuration.
• Apply stricter, multi-approver workflow paths specifically to high-risk changes such as bank details or vendor creation
• Build a fallback/escalation agent rule so workflow items never dead-end when primary agent determination fails to resolve.
• Build monitoring for CRs stuck in workflow beyond an expected SLA so stalled approvals are caught proactively
• Communicate to end users early that direct local maintenance will be restricted once governance goes live
• Confirm the deployment model (on-premise, private cloud, public cloud) before committing to a specific workflow customization approach with stakeholders.
• Confirm what extensibility for validations, derivations, and duplicate checks is actually supported in your specific S/4HANA deployment before designing custom rules
• Copy standard CR types rather than modifying delivered ones directly, and keep a clear naming convention distinguishing custom types by region or business line.
• Design change request types around risk categories, separating sensitive attributes like bank and tax data from routine changes
• Design multiple CR types segmented by risk and business object scope rather than one universal CR type
• Document the mapping between the BP data model and any legacy customer/vendor structures before configuration begins
• Document validation and derivation rules clearly so business and IT share a single source of truth on what is enforced and why
• Document validation and derivation rules in a shared rules catalog reviewed by both data stewards and functional consultants, not just IT.
• Document which deployment pattern (central governance, consolidation, or mass processing) applies to each phase of the rollout
• Engage business data stewards early to define what "good" Business Partner data looks like before configuring validation rules
• Establish a standard troubleshooting routine using change request status history and processing logs before escalating activation failures
• Include multiple identifying attributes such as tax ID, registration number, and address components, not just name, in match criteria
• Involve data stewards early to define what 'governed' means field by field, not just object by object
• Periodically review duplicate check hit rates and steward decisions to recalibrate match sensitivity
• Place duplicate checks before the approval step so approvers never sign off on records later found to be duplicates
• Plan a legacy data cleansing and consolidation phase before enforcing strict duplicate and validation rules
• Reserve hard-blocking validations for genuine data integrity risks and use warnings for softer business guidance
• Run a one-time cleansing and deduplication project on existing data before enforcing strict checks on new requests
• Scope governance to the BP roles and attributes that carry real business or compliance risk rather than governing everything by default
• Start governance scope with the highest-risk objects (for example, vendor bank details) rather than trying to govern every field on day one
• Test validation and derivation rules at every checkpoint in the CR lifecycle, not only the initial data entry screen
• Trigger an initial duplicate check as soon as core identifying attributes are captured, and a final check before workflow submission
• Tune duplicate check thresholds iteratively based on real false-positive and false-negative feedback from data stewards
• Validate deployment-specific capabilities (on-premise vs public cloud) before promising extensibility to business stakeholders

Failure analysis and operational risk

• Assuming a validation rule that works on the initial UI screen also fires consistently at later workflow steps without explicit testing
• Assuming BP governance automatically replaces all local master data maintenance without confirming which fields are actually governed centrally
• Assuming every SAP MDG deployment behaves identically across ECC, S/4HANA on-premise, and cloud editions without checking what is actually licensed and enabled
• Assuming MDG governance automatically replaces all local BP maintenance without explicitly configuring restrictions on direct local creation
• Assuming public cloud offers the same workflow builder flexibility as on-premise/private cloud, then discovering mid-project that custom multi-step workflow logic cannot be built the same way.
• Assuming S/4HANA Cloud Public Edition offers the same data model extensibility as on-premise MDG without checking current release constraints
• Assuming the same rule configuration and extensibility options are available identically across on-premise, private cloud, and public cloud editions
• Comparing against too narrow a set of attributes, so obvious duplicates with different name spellings are missed
• Configuring one generic CR type for all types of Business Partner changes instead of separating by risk and required control level
• Confusing processing status with business activity status when building worklist filters or reports, leading to incomplete or misleading governance dashboards.
• Copying a standard CR type but forgetting to also copy and reassign the associated workflow template, resulting in requests using an unintended default workflow.
• Defining one broad change request type covering both low-risk and financially sensitive attribute changes, weakening segregation of duties
• Enabling duplicate checks only on creation and not on significant changes such as address or tax ID updates, which can also introduce duplicates
• Failing to configure a clear rejection/resend-to-requester path, leaving rejected CRs as dead ends
• Failing to monitor false positive and false negative rates over time, leaving thresholds static as data patterns evolve
• Failing to review the change request processing log when activation fails, instead re-submitting the same request repeatedly without diagnosis
• Hardcoding individual named users as workflow approvers instead of using rule-based or role-based agent determination, creating maintenance and continuity risk.
• Ignoring a backlog of existing duplicates in production data, which erodes trust in new duplicate check results
• Ignoring duplicate check tuning, leading to either duplicate BP creation or requester frustration from excessive false positive matches
• Ignoring the need for change management training for end users who now must submit change requests instead of directly editing records
• Not aligning workflow approver rules with actual organizational authorization structure, causing approvals to route to the wrong team
• Not testing validation rules against edge-case country/data combinations before go-live, causing valid business partners to be blocked or invalid ones to pass silently.
• Placing duplicate check after approval instead of before, allowing approvers to sign off on records that turn out to be duplicates
• Setting all validations as hard blocking errors, which frustrates users with legitimate exceptions that need steward override
• Treating Business Partner governance as a pure IT/technical project rather than involving business data stewards who define validation and duplicate rules
• Treating every duplicate check hit as a hard block instead of allowing informed steward judgment for legitimate near-matches
• Treating the active area and staging area as interchangeable when troubleshooting missing or unexpected field values
• Underestimating the effort needed to harmonize existing legacy data before switching on central governance (the consolidation step)
• Underestimating the mapping effort between the harmonized BP model and legacy customer/vendor structures in ECC-based landscapes

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A consumer goods company implementing S/4HANA private cloud found that three regional ERP instances had created over 40,000 duplicate customer records over a decade, many with inconsistent tax IDs. The MDG program team's first workshop focused purely on data model scoping: deciding which BP roles (Customer, Vendor, Prospect) needed central governance versus which attributes could remain locally maintained. This scoping decision, made before any workflow or UI configuration, determined the entire project timeline and became the reference model for onboarding two more regions.

A financial services company governing supplier Business Partners configured a single change request type for all supplier changes, including bank detail updates. During an internal audit, it was flagged that address corrections and bank account changes went through the identical single-approver workflow, creating a segregation-of-duties gap for payment-critical data. The remediation project split the CR types by sensitivity, introducing a mandatory second-level finance approval specifically for bank detail changes, resolving the audit finding without disrupting low-risk address maintenance throughput.

A retail company's shared services team frequently received complaints that the same vendor was being created two or three times under slightly different name spellings, causing duplicate payments to be investigated by AP. After introducing a stricter attribute-based duplicate check that included tax registration number and bank account details alongside name and address, along with mandatory review of any hit above a certain similarity score, the volume of true duplicates dropped substantially within two quarters, though the volume of change requests requiring manual duplicate review increased and had to be staffed for during the initial tuning period.

A retail company operating in multiple countries had separate finance and sales teams creating customer and vendor records directly in each regional S/4HANA system. An internal audit found several vendors duplicated with slightly different tax IDs, leading to duplicate payments. The company implemented MDG central governance for Business Partner: all new customer and vendor creation was routed through MDG change requests with mandatory duplicate checks and tax ID validation, and direct BP creation in the regional systems was restricted for governed roles. Within two audit cycles, duplicate vendor incidents dropped significantly and the audit team could trace every master data change to a named requester and approver.

A manufacturing company configured a single generic Change Request type for all Business Partner changes, including low-risk address updates and high-risk bank detail changes, routed through the same two-step approval. Business users complained that simple address corrections took days to approve because they were stuck behind the same workflow used for sensitive financial changes. The project team split the single CR type into several purpose-specific CR types, each with workflow and approval steps calibrated to its actual risk level, which cut average turnaround time for routine changes while preserving strict dual-approval controls specifically for bank detail and vendor creation changes.

A retail company implementing MDG for Business Partner governance needed different approval paths for domestic (single approver, finance team) versus international vendor-related business partners (two-step approv

• Assuming a validation rule that works on the initial UI screen also fires consistently at later workflow steps without explicit testing
• Assuming BP governance automatically replaces all local master data maintenance without confirming which fields are actually governed centrally
• Assuming every SAP MDG deployment behaves identically across ECC, S/4HANA on-premise, and cloud editions without checking what is actually licensed and enabled
• Assuming MDG governance automatically replaces all local BP maintenance without explicitly configuring restrictions on direct local creation
• Assuming public cloud offers the same workflow builder flexibility as on-premise/private cloud, then discovering mid-project that custom multi-step workflow logic cannot be built the same way.
• Assuming S/4HANA Cloud Public Edition offers the same data model extensibility as on-premise MDG without checking current release constraints
• Assuming the same rule configuration and extensibility options are available identically across on-premise, private cloud, and public cloud editions
• Comparing against too narrow a set of attributes, so obvious duplicates with different name spellings are missed
• Configuring one generic CR type for all types of Business Partner changes instead of separating by risk and required control level
• Confusing processing status with business activity status when building worklist filters or reports, leading to incomplete or misleading governance dashboards.
• Copying a standard CR type but forgetting to also copy and reassign the associated workflow template, resulting in requests using an unintended default workflow.
• Defining one broad change request type covering both low-risk and financially sensitive attribute changes, weakening segregation of duties
• Enabling duplicate checks only on creation and not on significant changes such as address or tax ID updates, which can also introduce duplicates
• Failing to configure a clear rejection/resend-to-requester path, leaving rejected CRs as dead ends
• Failing to monitor false positive and false negative rates over time, leaving thresholds static as data patterns evolve
• Failing to review the change request processing log when activation fails, instead re-submitting the same request repeatedly without diagnosis
• Hardcoding individual named users as workflow approvers instead of using rule-based or role-based agent determination, creating maintenance and continuity risk.
• Ignoring a backlog of existing duplicates in production data, which erodes trust in new duplicate check results
• Ignoring duplicate check tuning, leading to either duplicate BP creation or requester frustration from excessive false positive matches
• Ignoring the need for change management training for end users who now must submit change requests instead of directly editing records
• Not aligning workflow approver rules with actual organizational authorization structure, causing approvals to route to the wrong team
• Not testing validation rules against edge-case country/data combinations before go-live, causing valid business partners to be blocked or invalid ones to pass silently.
• Placing duplicate check after approval instead of before, allowing approvers to sign off on records that turn out to be duplicates
• Setting all validations as hard blocking errors, which frustrates users with legitimate exceptions that need steward override
• Treating Business Partner governance as a pure IT/technical project rather than involving business data stewards who define validation and duplicate rules
• Treating every duplicate check hit as a hard block instead of allowing informed steward judgment for legitimate near-matches
• Treating the active area and staging area as interchangeable when troubleshooting missing or unexpected field values
• Underestimating the effort needed to harmonize existing legacy data before switching on central governance (the consolidation step)
• Underestimating the mapping effort between the harmonized BP model and legacy customer/vendor structures in ECC-based landscapes

• Always use rule-based or role-based agent determination rather than named-user hardcoding in workflow configuration.
• Apply stricter, multi-approver workflow paths specifically to high-risk changes such as bank details or vendor creation
• Build a fallback/escalation agent rule so workflow items never dead-end when primary agent determination fails to resolve.
• Build monitoring for CRs stuck in workflow beyond an expected SLA so stalled approvals are caught proactively
• Communicate to end users early that direct local maintenance will be restricted once governance goes live
• Confirm the deployment model (on-premise, private cloud, public cloud) before committing to a specific workflow customization approach with stakeholders.
• Confirm what extensibility for validations, derivations, and duplicate checks is actually supported in your specific S/4HANA deployment before designing custom rules
• Copy standard CR types rather than modifying delivered ones directly, and keep a clear naming convention distinguishing custom types by region or business line.
• Design change request types around risk categories, separating sensitive attributes like bank and tax data from routine changes
• Design multiple CR types segmented by risk and business object scope rather than one universal CR type
• Document the mapping between the BP data model and any legacy customer/vendor structures before configuration begins
• Document validation and derivation rules clearly so business and IT share a single source of truth on what is enforced and why
• Document validation and derivation rules in a shared rules catalog reviewed by both data stewards and functional consultants, not just IT.
• Document which deployment pattern (central governance, consolidation, or mass processing) applies to each phase of the rollout
• Engage business data stewards early to define what "good" Business Partner data looks like before configuring validation rules
• Establish a standard troubleshooting routine using change request status history and processing logs before escalating activation failures
• Include multiple identifying attributes such as tax ID, registration number, and address components, not just name, in match criteria
• Involve data stewards early to define what 'governed' means field by field, not just object by object
• Periodically review duplicate check hit rates and steward decisions to recalibrate match sensitivity
• Place duplicate checks before the approval step so approvers never sign off on records later found to be duplicates
• Plan a legacy data cleansing and consolidation phase before enforcing strict duplicate and validation rules
• Reserve hard-blocking validations for genuine data integrity risks and use warnings for softer business guidance
• Run a one-time cleansing and deduplication project on existing data before enforcing strict checks on new requests
• Scope governance to the BP roles and attributes that carry real business or compliance risk rather than governing everything by default
• Start governance scope with the highest-risk objects (for example, vendor bank details) rather than trying to govern every field on day one
• Test validation and derivation rules at every checkpoint in the CR lifecycle, not only the initial data entry screen
• Trigger an initial duplicate check as soon as core identifying attributes are captured, and a final check before workflow submission
• Tune duplicate check thresholds iteratively based on real false-positive and false-negative feedback from data stewards
• Validate deployment-specific capabilities (on-premise vs public cloud) before promising extensibility to business stakeholders

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers commonly probe whether a candidate understands that Business Partner is a role-based, relationship-driven model rather than a flat master record, and whether they can explain the practical difference between governing all BP attributes versus governing only compliance-critical fields. Being able to articulate the active-area versus staging-area concept in plain terms is a strong signal of hands-on MDG experience rather than theoretical knowledge.

A strong intermediate-level answer distinguishes between validation rules (blocking) and derivation rules (auto-populating), explains why change request type granularity affects both approval rigor and user experience, and can describe a realistic segregation-of-duties scenario involving bank data approval. Candidates who can explain how to troubleshoot a stuck or failed change request using status and processing logs demonstrate real production exposure rather than classroom-only knowledge.

Interviewers often probe whether a candidate understands that duplicate prevention is a tuning discipline, not a one-time switch. Be ready to discuss how you would design the timing of duplicate checks within a CR, how you would balance false positives against steward workload, and how you would approach cleansing existing duplicates before tightening checks on new data. Also expect questions distinguishing validation/derivation rules from duplicate search, since these are related but distinct governance mechanisms.

Interviewers commonly ask candidates to explain, in business terms, why an organization would introduce MDG for Business Partner rather than continuing to maintain BP records directly in each system, and to describe the difference between central governance, consolidation, and mass processing deployment patterns. Strong answers connect data quality problems (duplicates, inconsistent tax data, broken credit checks) to specific MDG capabilities (change requests, duplicate check, validation rules) rather than giving a generic definition of master data management.

Interviewers frequently probe whether a candidate understands that a Change Request is a staged, not-yet-active version of data until all workflow steps and approvals complete, and whether they can explain why certain changes (like vendor bank details) warrant stricter controls than others (like address updates). A strong candidate can also describe how to diagnose a stuck or failed CR by identifying whether the issue is at the workflow, validation, duplicate check, or activation stage, since production support roles are frequently evaluated on this triage skill.

Interviewers commonly probe whether a candidate understands the distinction between CR type, entity type, and workflow template, and can explain how agent determination is resolved dynamically rather than hardcoded. A strong answer also addresses how validation versus derivation rules differ in intent and execution point, and acknowledges that customization flexibility varies materially between on-premise/private cloud and public cloud deployments -- candidates who state deployment-specific capabilities with unwarranted certainty are often flagged as lacking hands-on breadth.