Configuring Change Request Types and Linking Workflow for Processing
Explains how to configure Change Request types, associate them with workflow templates, and understand the runtime processing flow from creation through approval and activation.
Explanation
Once the conceptual role of a Change Request is understood, the next practical step in an MDG implementation is configuring Change Request Types and connecting them to workflow so that CRs actually route to the right agents and enforce the right business logic. This lesson focuses on the configuration and runtime mechanics that intermediate-level consultants are expected to handle. A CR type configuration typically defines several linked elements: the governed business object or entity type (for example a business partner role group, material entity, or a custom-modeled governance object), the change document category (create, change, delete, or combinations like 'create and change'), the processing UI configuration (which floorplan or UI building blocks display which tabs and fields), and the workflow template that will be triggered when the CR is created. Configuration is done through IMG customizing activities dedicated to MDG, where you assign a workflow template ID to the CR type so that, at runtime, creating a CR of that type automatically starts the associated workflow process. Workflow templates in MDG use the standard SAP Business Workflow engine but are tailored to governance scenarios. Typical patterns include single-step approval, multi-step approval (e.g., regional steward then global steward), agent determination based on organizational responsibility (such as company code or purchasing organization derived from the data being changed), and parallel approval for cross-functional data (a business partner changed with both sales and finance-relevant fields might require both sales and finance approvers in parallel or sequential steps). Agent determination is a common configuration challenge: rules can be based on responsibility agents tied to org data, or on fixed agent assignment, and getting this wrong causes workflow items to route to nobody or to the wrong role, stalling the process. At runtime, the processing flow generally looks like this: a requester creates a CR of a given type, entering or changing the governed fields in staging; the CR immediately runs field-level validations (data type, mandatory field, format) as data is entered; upon submission, the CR triggers rule-based validations and, if configured, duplicate checks against existing master data; if validations pass, the workflow step advances to the first approval agent; the approver reviews staged data (often shown with before/after comparison), and can approve, reject, send back for correction, or forward; once all required approval steps complete successfully, the CR reaches a final processing step where the system activates the data, meaning it is copied from the staging tables into the active master data area and becomes available to reporting, transactional processing, and any configured replication to receiver systems. A key intermediate-level skill is being able to trace a CR's current state when something goes wrong: identifying which workflow step is open, which agent it is waiting on, and whether a validation or duplicate check is blocking activation. Common troubleshooting steps include checking the workflow log associated with the CR, verifying agent determination rules produced a valid agent, and confirming that no active validation rule is failing silently due to a configuration error such as a rule referencing a field that no longer exists in the current UI configuration. Deployment differences matter here too. In S/4HANA on-premise and private cloud, consultants typically have full access to IMG activities for CR type and workflow configuration, including custom BRFplus-based or rule-based validations layered into the process. In public cloud editions, workflow and CR type configuration is generally limited to SAP-provided templates and configuration keys exposed through simplified configuration apps, with less freedom to build fully custom multi-step approval chains; consultants should verify current scope rather than assuming on-premise-level customization is available.
Real project scenario
A utilities company governing business partner master data configured two CR types: 'BP Create - Customer' with a single steward approval, and 'BP Change - Bank Details' with a mandatory two-step approval (data steward then treasury) because bank detail changes are a fraud risk. During testing, treasury approvers were not receiving workflow items; investigation showed the agent determination rule referenced an organizational responsibility that had not been maintained for the new treasury team, so the workflow step had no valid agent and silently stalled until the responsibility rule was corrected.
Common mistakes
• Assigning one workflow template to multiple unrelated CR types, causing approval logic that fits one scenario poorly for another • Misconfiguring agent determination rules so approval steps have no valid agent, causing CRs to stall invisibly • Failing to test the full runtime flow (validation, duplicate check, workflow, activation) end to end before go-live, only testing configuration in isolation • Assuming public cloud editions support the same custom multi-step workflow configuration available on-premise • Not documenting which fields trigger which validation or approval branch, making support and troubleshooting difficult later
Best practices
• Separate CR types by business risk level so higher-risk changes (like bank details) get stronger approval chains • Test agent determination rules against realistic organizational data before go-live, not just default test users • Maintain a mapping document of CR type to workflow template to validation rules for support teams • Validate end-to-end runtime flow in a full regression test including activation and any downstream replication • Confirm workflow and CR type configuration capabilities available in your specific SAP MDG deployment edition before designing complex approval chains
Interview angle
A frequent question is how to troubleshoot a Change Request that appears stuck; a well-prepared answer walks through checking the workflow log for the current step, verifying agent determination produced a valid approver, and confirming no validation or duplicate check is blocking progress, showing systematic diagnostic thinking rather than guessing.