Configuring Workflow Steps and Agent Determination for Change Requests

Explanation

A change request in SAP MDG is only as useful as the governance process behind it, and that process is driven by the workflow configuration attached to the change request type. Every change request type references a workflow template (in on-premise and private cloud systems this is typically a standard or custom workflow built on the SAP Business Workflow framework, while public cloud editions expose this through simplified configuration apps rather than direct workflow builder access). Understanding how steps, statuses, and agents interact is essential for any consultant who needs to configure or troubleshoot approval flows. A change request workflow is composed of processing steps, each of which corresponds to a status in the change request status schema (such as 'In Process', 'To Be Approved', 'Approved', or 'Rejected'). Each step has an associated task, and each task needs an agent - the user or set of users who can act on it. Agent determination is the mechanism that resolves who those users are at runtime. In MDG this is commonly handled through rule-based agent determination, where rules can consider attributes such as the entity type being changed, the requesting business unit, the material group, the company code, or organizational assignments held in the user's HR or business partner master data. Consultants configure these rules by mapping specific criteria to responsible roles or individual agents, and the workflow engine evaluates the rules whenever a step becomes active. A critical design decision is whether to use single-step or multi-step approval. Single-step approval is simpler and faster but offers less governance rigor; multi-step approval (for example, data steward review followed by finance approval for cost-relevant fields) gives stronger control but increases processing time and support complexity. The number of steps should match the actual business risk of the data change, not be added indiscriminately, because each additional step is a potential bottleneck and a source of processing delays if agent determination is misconfigured. At runtime, when a request moves into a step, the system evaluates the agent determination rule, and if no agent is found the request typically falls into an error queue or is routed to a fallback agent (a supervisor or workflow administrator) - if fallback is not configured, the request can appear 'stuck' with no visible processor, which is one of the most common production support issues in MDG. Troubleshooting stuck requests usually starts by checking the current status and step, verifying the agent determination rule inputs (does the entity have all required organizational data to be evaluated by the rule?), and confirming that assigned users are still valid and have not left the relevant role or organizational unit. In S/4HANA private cloud and on-premise, workflow configuration is done through the workflow customizing transactions and rule maintenance tools tied to the Business Rule Framework or classic rule resolution, giving consultants fine control over conditions. In S/4HANA Cloud Public Edition, the configuration is more guided: business users or key users typically define approval steps and responsible roles through Fiori-based configuration apps with pre-delivered scenarios, and the underlying workflow technical objects are largely hidden. This means public cloud implementations trade flexibility for faster, less error-prone setup, but complex conditional routing that is easy in on-premise may not be achievable at all in public cloud without extension development, and consultants must validate this early rather than assuming full parity. Another important aspect is escalation and reminder handling. Well-designed workflows include reminder notifications after a defined dwell time in a step and, in mature designs, an escalation path to a manager if a step remains unprocessed beyond a threshold. Reminder and escalation timing should be tuned based on realistic business cadence (e.g., daily batch reviews vs near-real-time approvals) rather than left at technical defaults, since overly aggressive reminders create alert fatigue and overly lax ones let stale requests accumulate. Finally, testing agent determination rules requires representative test data across all organizational variations before go-live: consultants should test with entities lacking optional attributes, entities spanning multiple organizational units, and entities that should trigger no valid agent, to confirm fallback behavior works as intended rather than silently failing.

Code example

Example: simplified agent determination rule logic (pseudocode, not a specific SAP API) RULE: Determine_Approver_For_CostCenter_ChangeINPUT: entity_type = 'CostCenter', field_changed, controlling_area, company_code IF field_changed IN ('cost_center_category','profit_center_assignment') THEN    responsible_role = 'FI_CONTROLLING_APPROVER'    lookup_agent BY controlling_areaELSE IF field_changed IN ('cost_center_name','cost_center_description') THEN    responsible_role = 'DATA_STEWARD'    lookup_agent BY company_codeELSE    responsible_role = 'FALLBACK_ADMIN'END IF OUTPUT: agent_list -- Note: actual implementation uses the workflow agent determination-- and rule resolution mechanisms configured for the change request type;-- this pseudocode illustrates the decision logic consultants must design,-- not a literal system syntax.

Real project scenario

During an S/4HANA private cloud MDG rollout for a multinational manufacturer, the project team configured a two-step approval for cost center changes: data steward review followed by controlling approval for financially sensitive fields. Shortly after go-live, several change requests in Eastern Europe entities stalled at the controlling approval step because the agent determination rule relied on a controlling area attribute that was blank for a newly onboarded company code. The consultant traced the issue by checking the request's current step and status, identifying the missing organizational data, and adding a fallback rule that routed unresolved cases to a regional controlling administrator group while the master data gap was corrected. This established a permanent fallback pattern used across all financially sensitive change request types going forward.

Common mistakes

• Assuming public cloud MDG configuration apps offer the same conditional routing flexibility as on-premise workflow rule maintenance • Not configuring a fallback agent, leaving change requests unprocessable when a rule resolves to zero agents • Adding excessive approval steps that do not match the actual risk of the data change, slowing down routine updates • Failing to test agent determination against entities with missing or unusual organizational attributes before go-live • Overlooking reminder and escalation configuration, leading to requests aging indefinitely without visibility • Hardcoding individual users as agents instead of roles or positions, which breaks when staff change

Best practices

• Always configure a fallback agent or escalation path for every agent determination rule • Match the number of approval steps to actual business risk, not maximum theoretical governance • Use roles or organizational positions as agents rather than named individuals • Test agent determination rules with incomplete and edge-case master data before go-live • Configure reminders and escalations aligned to realistic business processing cadence • Document rule logic and its data dependencies so support teams can diagnose stuck requests without full system access • Validate early in public cloud engagements whether required routing complexity is achievable through standard configuration apps

Interview angle

Interviewers assess whether a candidate understands that change request governance is really a workflow and rule design problem, not just a status list. Strong answers explain how agent determination rules resolve responsible approvers dynamically, why fallback agents are essential, how step count should reflect business risk, and how they diagnosed a real 'stuck request' scenario by checking status, step, and rule inputs rather than guessing.