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.
Explanation
Once the Business Partner data model and governance scope are defined, the operational core of MDG is the change request (CR) process. A change request is the transactional container that carries a proposed create, update, or mark-for-deletion action on one or more Business Partner entities through a controlled lifecycle: creation, processing, validation, approval, and activation. Understanding this lifecycle in depth is essential for any intermediate-level MDG consultant because most production issues - stuck requests, incorrect approvals, data not appearing downstream - trace back to a misunderstanding of how the CR interacts with workflow and rules. A change request is configured against a change request type, which determines what entities and operations are in scope (for example, a CR type dedicated to new Customer creation versus one for bank detail changes only). This granularity matters because it lets an organization apply different approval rigor to different kinds of changes: creating a brand-new supplier with banking information might require a two-step approval (data steward plus finance approver), while a simple address correction might be single-step or even auto-approved under defined conditions. Configuring CR types too broadly is a common design mistake that leads to either bottlenecked approvals for trivial changes or insufficiently controlled approvals for sensitive changes like bank data. Workflow is the mechanism that routes the change request to the correct approvers. MDG workflow is typically built on standard business workflow technology, using agent determination rules to decide who receives a work item - by organizational responsibility, region, BP role, or a combination via rule-based agent determination. A well-designed workflow separates duties: the requester (often a shared service or regional team) creates or edits data, while an independent approver validates it, which is particularly important for financially sensitive attributes like bank account details or tax registration numbers, where segregation of duties reduces fraud risk. Validation and derivation rules execute at defined checkpoints in the CR lifecycle. Validation rules block progression (for example, a CR cannot move to approval status if a mandatory tax ID is missing or fails a check-digit rule), while derivation rules automatically populate or adjust fields to reduce manual entry errors (for example, deriving a default payment term from country and customer group). These rules run at UI level for immediate feedback and again at defined process steps to ensure that even changes made through less controlled entry paths do not bypass quality checks. Consultants need to understand that a rule failing silently at one checkpoint but not another is a frequent root cause of 'data got through that should have been blocked' incidents, so testing rules across all relevant checkpoints - not just the initial UI screen - is essential. Duplicate checks are commonly integrated into the CR flow for Business Partner, especially at creation, to prevent redundant customer or supplier records. Depending on configuration and deployment, this may leverage fuzzy search capabilities to flag likely duplicates before a requester proceeds, requiring either justification to continue or escalation to a data steward. This integration point is a frequent area of both value and friction: overly aggressive duplicate matching creates false positives that frustrate requesters, while overly loose matching lets true duplicates through. Finally, activation is the step where an approved change request writes its data from the staging/process area into the active area, making it consumption-ready and, in later stages of the governance chain, eligible for replication to target systems. Activation can fail due to technical inconsistencies (for example, a dependent object not yet active) and understanding how to diagnose a failed or partially activated change request - checking the CR's processing log and status history - is a core production support skill.
Real project scenario
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.
Common mistakes
• Defining one broad change request type covering both low-risk and financially sensitive attribute changes, weakening segregation of duties • Assuming a validation rule that works on the initial UI screen also fires consistently at later workflow steps without explicit testing • Ignoring duplicate check tuning, leading to either duplicate BP creation or requester frustration from excessive false positive matches • Failing to review the change request processing log when activation fails, instead re-submitting the same request repeatedly without diagnosis
Best practices
• Design change request types around risk categories, separating sensitive attributes like bank and tax data from routine changes • Test validation and derivation rules at every checkpoint in the CR lifecycle, not only the initial data entry screen • Tune duplicate check thresholds iteratively based on real false-positive and false-negative feedback from data stewards • Establish a standard troubleshooting routine using change request status history and processing logs before escalating activation failures
Interview angle
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.