Configuring Change Request Types and Workflow for Business Partner Governance

Explanation

In SAP MDG, every governed change to master data flows through a Change Request (CR). The CR is the transactional container that groups the affected business partner entities, the requested field-level changes, the processing status, and the workflow instance driving approval. Understanding how CR types, entity types, and workflow templates interact is fundamental for any consultant configuring or troubleshooting Business Partner governance. A CR type is a configuration object that determines: which business object types and entity types can be edited (for example Business Partner, Customer role data, Vendor role data, or Business Partner relationships), which workflow template is triggered, whether single-object or multi-object processing is allowed, and which UI configuration (Floorplan Manager based UIBB configuration in on-premise/private cloud, or Fiori-based UI in newer releases) is used to present the data. SAP delivers standard CR types as templates, but in almost every implementation these are copied and adapted because business rules around approval hierarchies, segregation of duties, and role-based create-vs-change flows differ by organization. The workflow template attached to a CR type is typically built using standard workflow tools available in the on-premise/private cloud stack, and determines the sequence of processing steps: initial data entry, one or more approval steps (which may be single approver, parallel approval, or rule-driven agent determination), and final activation. Agent determination is a critical design decision -- rather than hardcoding approvers, most implementations use rule-based agent determination so that the correct approver is resolved dynamically based on attributes of the request, such as country, business partner category (person, organization, group), or requesting business unit. This keeps governance maintainable as personnel change. Processing status and business activity status are two related but distinct concepts consultants often confuse. Business activity status reflects what the CR intends to do (create, change, delete), while processing status reflects where the CR is in its lifecycle (in process, to be approved, approved, rejected, completed). Reporting and worklists typically filter on both. Validation and derivation rules execute at defined points in the CR lifecycle -- commonly at save and at each step transition. Validations block progression when data fails a business rule (for example, a tax number format check or mandatory field check for a specific country), while derivations automatically populate or default fields (for example, deriving a business partner grouping or a standard address format) without requiring the requester to enter them manually. Rules are typically built using a business rules framework rather than hardcoded logic, allowing business analysts or configuration consultants to maintain them without full ABAP development, though complex rules may still require custom logic. In S/4HANA public cloud, the extensibility model for CR types and workflow is more constrained: SAP provides pre-delivered change request scenarios and configuration is done largely through guided configuration (SSCUI-equivalent) apps and the extensibility framework, with less freedom to build fully custom workflow templates compared to on-premise or private cloud, where classic workflow builder access and BAdI-based extensions remain available. Consultants must confirm which deployment they are on before promising a specific customization approach, since capabilities that are standard in on-premise governance may require alternative extensibility patterns or may not be available in public cloud. Troubleshooting a stuck CR typically starts with checking the workflow log to see which step and which agent the item is waiting on, verifying agent determination rules resolved to a valid, active user or role, and checking whether a validation rule is silently blocking transition without a clear user-facing message. Reprocessing a CR after a technical error, versus rejecting and creating a new one, is a decision that depends on whether the underlying data lock or workflow instance is recoverable -- this should follow your organization's support procedures rather than ad hoc reprocessing.

Code example

* Illustrative BRFplus-style pseudocode for a validation rule* attached to a Business Partner Change Request step* (actual implementation uses the rules framework UI, not raw ABAP,* but this pseudocode shows the intended logic for documentation) RULE: VALIDATE_TAX_NUMBER_FORMATINPUT: BP_COUNTRY, BP_TAX_NUMBERCONDITION:  IF BP_COUNTRY = 'DE' AND NOT MATCHES(BP_TAX_NUMBER, 'DE[0-9]{9}')  THEN RAISE_MESSAGE(         SEVERITY = ERROR,         TEXT = 'German tax number must start with DE followed by 9 digits' ) RULE: DERIVE_BP_GROUPINGINPUT: BP_CATEGORY, BP_COUNTRYCONDITION:  IF BP_CATEGORY = '2' (Organization) AND BP_COUNTRY = 'US'  THEN SET BP_GROUPING = 'ORGUS'  ELSE IF BP_CATEGORY = '1' (Person)  THEN SET BP_GROUPING = 'PERSN' * These rules are typically executed at the 'check' event* during CR save and at step transition in the workflow.

Real project scenario

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 approval: regional data steward, then global compliance). The team configured two CR types differentiated by a custom attribute captured during initiation, each pointing to a distinct workflow template with rule-based agent determination keyed on the business partner's country group. During hypercare, several CRs stalled because the agent determination rule referenced a organizational unit that had not yet been maintained in the org structure for two newly onboarded countries, causing workflow items to route to no valid agent. The fix involved correcting the org assignment and adding a fallback agent rule so future gaps would route to a central governance team instead of failing silently.

Common mistakes

• Copying a standard CR type but forgetting to also copy and reassign the associated workflow template, resulting in requests using an unintended default workflow. • Hardcoding individual named users as workflow approvers instead of using rule-based or role-based agent determination, creating maintenance and continuity risk. • Confusing processing status with business activity status when building worklist filters or reports, leading to incomplete or misleading governance dashboards. • 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. • 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.

Best practices

• Always use rule-based or role-based agent determination rather than named-user hardcoding in workflow configuration. • Copy standard CR types rather than modifying delivered ones directly, and keep a clear naming convention distinguishing custom types by region or business line. • Build a fallback/escalation agent rule so workflow items never dead-end when primary agent determination fails to resolve. • Document validation and derivation rules in a shared rules catalog reviewed by both data stewards and functional consultants, not just IT. • Confirm the deployment model (on-premise, private cloud, public cloud) before committing to a specific workflow customization approach with stakeholders.

Interview angle

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.