Agent Determination, Escalation and Exception Handling in MDG Change Request Workflows

Explanation

Once a Change Request (CR) type and its workflow template are configured, the hardest part of making governance workflow actually run in production is getting the right work item to the right person at the right time. Agent determination in MDG is not a single mechanism - it is a layered decision that combines the workflow template's step definitions, business rule outcomes, organizational responsibility data, and fallback logic. A workflow step can be configured to route to a fixed user, a role, a responsible agent derived from a BRF+ (or equivalent rule) decision such as company code or region, or a determined data steward tied to the governed entity's attributes (for example, the material's plant or the business partner's country). When rule-based agent determination is used, the rule sits alongside the CR's business validation rules but serves a different purpose: it does not validate data, it decides who acts next. This distinction matters in interviews and in production debugging - a CR stuck in a step is often not a data problem but an agent determination problem where the rule returned no result, multiple results, or an inactive user. Escalation is the second core concept. Because governance CRs often have SLA expectations (for example, financial master data changes reviewed within a business day), workflow deadlines can be attached to steps. When a deadline passes without action, the system can trigger a reminder, escalate to a substitute or manager, or route to a fallback agent group. Escalation configuration typically leverages standard workflow deadline monitoring capabilities; the specific deadline type (requested start, latest end) determines whether the escalation fires before or after the expected completion time. Consultants must align these deadlines with realistic business SLAs, not default values, because overly aggressive escalation floods inboxes and undermines confidence in the process, while overly loose escalation lets critical CRs stall unnoticed. Exception handling covers what happens when the happy path breaks: an agent rejects a CR, a step has no valid agent, or a technical error occurs during a background validation call inside the workflow. Rejection paths usually route the CR back to the requester or to a prior step, often with mandatory rejection reason capture so downstream steps understand why the CR is coming back. No-agent situations are dangerous because they leave a work item orphaned; production designs must include a fallback substitute or administrator role to prevent silent workflow stalls. Technical errors inside a step (for example, a data quality service temporarily unavailable) should be caught and surfaced as a workflow error work item to an administrator queue rather than allowed to block the entire CR silently. Integration-wise, agent determination often needs to read organizational or master data that itself lives in governed objects (such as responsible cost center owner), creating a dependency loop consultants should map out during design. Runtime flow: CR created -> workflow template instantiated -> step 1 rule evaluated -> agent(s) determined -> work item created -> deadline clock starts -> action taken or deadline exceeded -> escalation or next step. Troubleshooting typically starts by checking whether the responsible rule returned the expected result for the specific data values in the failing CR, then checking whether the resolved user/role is active and has appropriate authorization, and finally checking the workflow log for step-level errors. In S/4HANA on-premise and private cloud, custom BRF+ style agent rules and organizational model extensions are common; public cloud environments generally constrain customization to configured extension points and predefined determination strategies, so parity of custom logic between environments should never be assumed.

Code example

* Illustrative pseudo-logic for a rule-based agent determination step (not literal ABAP)* Step: 'Regional Data Steward Review' in a Business Partner CR workflow Determine_Agent(CR):    region = CR.BusinessPartner.Region    IF region IN ('EMEA'):        agent_role = 'BP_STEWARD_EMEA'    ELIF region IN ('APAC'):        agent_role = 'BP_STEWARD_APAC'    ELSE:        agent_role = 'BP_STEWARD_DEFAULT'   * fallback to avoid no-agent stall     IF NO_ACTIVE_USER_IN(agent_role):        agent_role = 'MDG_WORKFLOW_ADMIN'   * escalation fallback     RETURN agent_role * Deadline example (conceptual):* Step latest-end deadline = CR.CreatedOn + 1 business day* On deadline exceeded -> send reminder to agent_role, escalate to manager after +4 hours

Real project scenario

A global chemicals company implemented MDG governance for business partner master data with region-based stewardship. Early in hypercare, several CRs for a newly onboarded country stalled because the regional rule table had no entry for that country code, so agent determination returned no result and work items sat unassigned. The support team added a mandatory default fallback role and a daily report of CRs without an assigned agent, which caught the gap immediately in the next country rollout and prevented a repeat stall.

Common mistakes

• Configuring rule-based agent determination without a fallback agent, causing silent stalls when a rule returns no match • Setting escalation deadlines from generic templates instead of validated business SLAs, leading to alert fatigue or missed critical CRs • Not capturing or displaying rejection reasons, forcing requesters to guess why a CR was sent back • Assuming agent determination rules behave identically across environments when public cloud extensibility is more constrained • Failing to monitor for orphaned or errored work items, letting governance CRs silently disappear from active queues • Granting broad fallback administrator access as a permanent workaround instead of fixing the underlying rule gap

Best practices

• Always define a fallback agent or administrator role for every rule-based determination step to prevent orphaned work items • Base escalation deadlines on validated business SLAs agreed with stakeholders, not template defaults • Require structured rejection reasons so requesters and stewards have clear, auditable context • Build a monitoring report or dashboard for CRs with no agent, exceeded deadlines, or workflow errors • Document environment-specific extensibility limits for agent rules, especially in public cloud, to avoid promising unsupported customization • Periodically review and prune agent determination rule tables as organizational structures change to prevent stale routing

Interview angle

Interviewers often probe whether a candidate understands agent determination as a distinct decision layer from data validation rules, and whether they have handled real stalled-workflow incidents. Be ready to explain the difference between rule-based, role-based, and fixed-agent routing, how deadline-based escalation is triggered, and a concrete example of diagnosing a no-agent or rejected-CR scenario, since this shows production support maturity rather than only configuration knowledge.