Configuring Workflow Steps and Agent Determination for Change Requests

Explanation

Once a Change Request type is defined against a governed data model, the next configuration layer is the workflow that drives the CR through its lifecycle. In SAP MDG, workflow configuration typically involves defining the sequence of processing steps a Change Request goes through, the possible outcomes at each step (approve, reject, send back for correction), and the rules that determine which user or role is responsible for acting on each step. A simple workflow might have three steps: Create/Edit by a requester, Review by a specialist, and Approve/Activate by a data steward; more complex workflows can include parallel review branches, escalation steps, or conditional routing based on data attributes such as company code, region, or change type. Agent determination is the mechanism that decides who receives a given workflow step in their inbox. Rather than hardcoding individual usernames, SAP MDG governance workflow is generally configured to use rule-based agent determination, where responsibility is derived from organizational attributes present in the Change Request data, such as purchasing organization, controlling area, or business partner category. This is commonly implemented through workflow rules or a business rules component that evaluates the CR's data context and returns the appropriate processing role or position. Using rules rather than fixed assignments keeps the workflow maintainable as staff change and as organizational structures evolve, since only the underlying rule logic or organizational assignment needs updating, not the workflow definition itself. A critical design decision is how granular to make the workflow steps. Too few steps and the process loses meaningful control points; too many steps and the process becomes slow and creates processing fatigue, causing approvers to click through requests without real review. Experienced consultants typically start with the minimum steps needed to satisfy segregation-of-duties and data quality requirements, then add complexity only where a genuine business risk justifies it, such as a dedicated compliance check step for sensitive attributes like banking data or tax identifiers. Step configuration also needs to account for what happens on rejection or send-back: does the Change Request return to the original requester with comments, or does it route to a different correction role? Clear rejection routing prevents change requests from stalling indefinitely in an ambiguous state. Similarly, escalation handling for steps that are not processed within an expected time frame is a common production requirement, often addressed through workflow deadline monitoring so that stalled requests are visible to a supervisor or administrator rather than silently aging. Integration points matter here too: validation and derivation rules typically execute before or during workflow steps to ensure that by the time a step reaches a human approver, obvious data errors have already been caught, keeping the human review focused on judgment calls rather than mechanical checks. Duplicate check services may also run automatically at creation, before the workflow even starts, to avoid routing an obvious duplicate through several approval steps unnecessarily. Across SAP MDG on S/4HANA on-premise and private cloud, workflow and agent determination configuration is generally accessible and customizable by the implementation team using the governance framework's configuration activities. In public cloud or more restricted SaaS-style deployments, the degree of custom workflow step design and rule modification may be more limited or delivered through predefined content, so implementers should confirm what level of workflow customization the specific product edition and contract actually permit before committing to a complex multi-step design.

Code example

* Illustrative pseudo-representation of a workflow rule outcome,* not an actual ABAP class or BAdI signature.* Purpose: derive the responsible processor role for a Change Request step* based on data present in the CR container. METHOD determine_agent_for_step.  " Read relevant business attribute from the change request context  DATA(lv_company_code) = cr_context-company_code.  DATA(lv_change_type)  = cr_context-change_type.   " Simple illustrative rule logic (actual implementation uses  " configured business rules / organizational assignment, not  " hardcoded IF logic in production)  IF lv_change_type = 'BANK_DATA_CHANGE'.    rv_responsible_role = 'COMPLIANCE_REVIEWER'.  ELSEIF lv_company_code = '1000'.    rv_responsible_role = 'DATA_STEWARD_1000'.  ELSE.    rv_responsible_role = 'DATA_STEWARD_DEFAULT'.  ENDIF.ENDMETHOD.

Real project scenario

During an SAP MDG finance master data rollout, the project team initially assigned every change request approval to a single central finance role, which quickly became a bottleneck as volumes grew across multiple company codes. The team reconfigured agent determination to route steps based on company code, splitting approval workload across regional data stewards, which reduced average processing time and made escalation ownership clearer when a request stalled.

Common mistakes

• Hardcoding individual user names as workflow agents instead of using rule-based or role-based determination. • Designing workflows with excessive sequential steps that slow down routine, low-risk changes. • Failing to define clear rejection or send-back routing, leaving rejected requests in an ambiguous state. • Not testing agent determination rules against edge cases, such as change requests spanning multiple organizational units. • Assuming full custom workflow step design is available in every SAP MDG deployment option without checking product-specific constraints.

Best practices

• Start with a minimal, risk-justified set of workflow steps and add complexity only where a real control gap exists. • Use rule-based or organizational-role-based agent determination rather than hardcoded user assignments. • Define explicit rejection and escalation routing so change requests cannot stall indefinitely. • Run duplicate checks and validation/derivation rules early so human approvers focus on judgment, not mechanical errors. • Confirm the level of workflow customization permitted in the specific SAP MDG deployment before finalizing design.

Interview angle

A common interview question asks how you would design an approval workflow that avoids becoming a bottleneck while still meeting segregation-of-duties requirements; strong candidates discuss balancing step count, rule-based agent determination, and risk-based routing rather than defaulting to the most complex workflow possible.