Change Request Types and Workflow for Business Partner Governance

Explanation

Once an organization decides to govern Business Partner data centrally, the mechanism that enforces that governance is the Change Request (CR). A Change Request is a governed container for one or more data changes: creating a new Business Partner, changing an address, adding a role, or updating bank details. Every CR is based on a CR type, which is configured to determine what business objects and entities it can touch (for example, a CR type scoped to "Create Business Partner - Customer" versus one scoped to "Change Bank Details Only"), which processing steps and workflow the request follows, and which authorizations are required at each step. When a requester initiates a CR, the system creates a staging area version of the affected Business Partner record. This staged version is not yet active in the productive BP tables; it exists as a work-in-progress version tied to the CR. As the requester enters data through the UI, field-level and entity-level checks run: mandatory field checks, format validations, and business rule derivations (for example, automatically deriving a reconciliation account based on customer account group, or defaulting a payment term based on country). These checks can be configured to block progress (hard errors) or merely warn the user (soft warnings), and this distinction is a key configuration decision: overly strict validation slows down legitimate changes, while overly lenient validation lets bad data through. Duplicate checking is typically integrated at a specific processing step in the CR, most commonly right after data entry and before the request is submitted for approval. The duplicate check compares key attributes (name, address, tax number, or other matching fields depending on configuration) against existing active Business Partners and flags potential matches with a similarity score. Depending on configuration, a high-confidence match can block the CR from proceeding, while lower-confidence matches may require the requester or a data steward to review and confirm the record is genuinely new before continuing. After data entry and duplicate check steps, the CR moves into workflow-based approval. SAP MDG uses SAP Business Workflow to route the request to one or more approvers based on rules such as the CR type, the requesting organizational unit, or the monetary/criticality threshold of the change (for example, changes to vendor bank details often require a second, independent approver as a fraud control, sometimes called dual control or segregation of duties). Approvers see a comparison of old versus new values (for change CRs) or the full proposed record (for create CRs) and can approve, reject, or send the request back to the requester for correction with comments. Only when the CR completes all required processing steps and receives all required approvals does the system activate the data: the staged version replaces or creates the productive Business Partner record, and the CR status changes to completed. At that point, if replication is configured, the newly activated data is distributed to subscribing systems, typically through the Data Replication Framework, either immediately or on a scheduled basis depending on the outbound configuration. Understanding the CR lifecycle is essential for troubleshooting: a CR stuck "in process" usually means it is waiting at a workflow step for an approver, a CR that fails to activate usually indicates a validation or derivation error surfaced late in processing, and data that appears correct in MDG but not in the target system usually points to a replication or mapping issue downstream of activation, not a governance-step problem. Distinguishing these failure domains quickly is a core production support skill.

Code example

Example: Simplified representation of a Change Request configuration decision table (illustrative, not literal SAP configuration syntax) CR_TYPE            | SCOPE                        | DUPLICATE_CHECK | APPROVAL_STEPSBP_CREATE_CUST      | Create Customer BP + Role    | Yes (blocking)   | 1 (Data Steward)BP_CREATE_VEND       | Create Vendor BP + Role      | Yes (blocking)   | 2 (Steward + Finance)BP_CHANGE_BANK        | Change Bank Details Only    | No               | 2 (Requester's Manager + Treasury)BP_CHANGE_ADDRESS      | Change Address Only        | No               | 1 (Data Steward) This table illustrates how different CR types can carry different risk profiles: bank detail changes route through Treasury for a segregation-of-duties control even though no duplicate check is relevant, while new vendor creation combines both duplicate checking and a two-step approval because it introduces new financial exposure.

Real project scenario

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.

Common mistakes

• Configuring one generic CR type for all types of Business Partner changes instead of separating by risk and required control level • 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 • Failing to configure a clear rejection/resend-to-requester path, leaving rejected CRs as dead ends • Not aligning workflow approver rules with actual organizational authorization structure, causing approvals to route to the wrong team

Best practices

• Design multiple CR types segmented by risk and business object scope rather than one universal CR type • Place duplicate checks before the approval step so approvers never sign off on records later found to be duplicates • Reserve hard-blocking validations for genuine data integrity risks and use warnings for softer business guidance • Apply stricter, multi-approver workflow paths specifically to high-risk changes such as bank details or vendor creation • Build monitoring for CRs stuck in workflow beyond an expected SLA so stalled approvals are caught proactively

Interview angle

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.