SAP MDG Change Requests Interview Questions

This topic covers Change Requests (CRs) in SAP Master Data Governance: the core object that packages proposed master data changes, drives workflow-based approval, enforces validation and duplicate checks, and controls when data becomes active in the governance and consolidation layers. Lessons progress from foundational concepts to configuration and processing details needed for real MDG implementations on S/4HANA. Key lesson areas: Change Request Runtime Flow: Status Management, Agent Determination, and Troubleshooting Stuck Requests; Change Request Types, Steps, and Core Configuration Building Blocks; Configuring Change Request Types and Linking Workflow for Processing; Configuring Workflow Steps and Agent Determination for Change Requests; Understanding the Role of Change Requests in MDG Governance; What a Change Request Is and Why MDG Uses It Explains how CR types are configured with entity types, processes, and workflow steps, and how these building blocks combine to control what a requester sees and who must approve. Explains how to configure Change Request types, associate them with workflow templates, and understand the runtime processing flow from creation through approval and activation. Introduces the Change Request as the core governance object in SAP MDG, explaining why raw master data edits are not allowed and how a CR bundles data, workflow, and audit trail together. Introduces what a Change Request is in SAP MDG, why it exists, and how it enables controlled, auditable master data changes across create, change, and mark-for-deletion scenarios. Learn how MDG change request types are linked to workflow templates, how processing steps are sequenced, and how agent determination rules assign the correct approvers and processors at each step. Understand how a change request moves through its lifecycle at runtime, how agents are determined for each workflow step, and how to diagnose and resolve requests that get stuck, skip steps, or fail to route correctly in production.

Introduces the Change Request as the core governance object in SAP MDG, explaining why raw master data edits are not allowed and how a CR bundles data, workflow, and audit trail together. Deep explanation: In SAP MDG, a Change Request (CR) is the mandatory container object through which almost all governed master data changes flow. Unlike a classic transactional system where a user might directly edit a customer or material record in a table, MDG deliberately blocks direct changes to active, consolidated master data. Instead, every create, change, mark-for-deletion, or (in some models) delete operation on a governed entity must be proposed inside a Change Request, which then moves through a defined workflow before the data is written to the active area and, where configured, replicated to connected systems. Why does this matter for a project team? Master data errors are expensive: a wrong tax classification, an incorrect vendor bank detail, or a duplicate business partner can cause payment errors, compliance issues, or reporting inconsistencies across ERP, CRM, and analytics systems. The CR mechanism exists to insert a controlled checkpoint between 'someone wants to change data' and 'the data is actually changed everywhere.' That checkpoint provides three things: (1) a workflow-driven approval chain so the right people review sensitive changes, (2) validation and derivation logic that runs at defined points so bad data is caught early, and (3) a complete audit trail showing who requested what, who approved it, and when it became active. Structurally, a CR is created against a CR type, which is configured to work with one or more governance scope entities (for example Business Partner, Customer, Supplier, Material, or a custom governed object depending on the domain being governed). When a requester starts a CR, they choose (or the system defaults) a CR type, and the system opens a corresponding UI where the requester enters or changes attribute values. Internally, the proposed values are held in a staging area separate from the active master data; the active data is untouched until the CR completes successfully. This separation is what allows the requester to save a CR in draft, come back later, or have it rejected without ever having touched production-consumable data. Every CR has a status (such as in process, in approval, completed, or rejected, with exact status names depending on configuration) and moves along a workflow that was defined for its CR type. Even a 'single-level' governance process, where only the requester interacts with the system, technically still uses a CR and a (often very short) workflow, because the CR is what holds staging data, validation results, and history. This is a key beginner point: even simple, low-risk changes are not exempt from the CR concept; only the number of workflow steps and approvers varies. From an S/4HANA perspective, the concept is consistent whether you are on-premise, private cloud, or public cloud, but the amount of pre-delivered configuration you can change differs. On-premise and private cloud environments generally allow more customization of CR types, workflow steps, and data models. Public cloud editions of MDG-related capabilities typically expose pre-configured governance scenarios with more limited extensibility, so project teams should not assume every knob seen in an on-premise system is adjustable in a public cloud tenant. A consultant new to MDG should first learn to recognize a CR in the UI (its ID, type, status, and workflow log) before moving into configuration details, because troubleshooting always starts with asking 'which CR is this data stuck in, and what step is it at.' Recommended practices: • Always identify the CR type and current workflow step before diagnosing a reported data issue. • Educate business users early that all governed changes, however minor, go through a CR, to avoid adoption friction. • Keep a clear mapping of which CR types apply to which governed entities so support staff are not guessing. • Distinguish clearly in documentation and training between staging (in-process) data and active (published) data. • Confirm with the platform team whether the deployment is on-premise, private cloud, or public cloud before promising configuration changes to CR behavior. Common mistakes to challenge: • Assuming a 'simple' change can bypass the CR mechanism entirely instead of using a lightweight CR type with minimal steps. • Confusing the staging (proposed) data shown inside an open CR with the active, already-governed master data. • Not checking the CR status and workflow log first when a user reports 'my change did not save,' leading to wasted troubleshooting time. • Expecting the same CR type configuration options to be available in a public cloud tenant as in an on-premise system. • Treating CR terminology as one-size-fits-all across every governed domain without confirming which entity types a given CR type actually supports. Interview angle: Interviewers commonly ask candidates to explain, in plain language, why MDG does not allow direct table-level changes to master data and what role the Change Request plays i

Introduces what a Change Request is in SAP MDG, why it exists, and how it enables controlled, auditable master data changes across create, change, and mark-for-deletion scenarios. Deep explanation: In SAP Master Data Governance, a Change Request (CR) is the transactional container that wraps every proposed create, change, or deletion of governed master data (such as business partner, material, or custom domain objects) so that nothing is written directly to the active master data table without going through review, validation, and approval steps. This matters because master data errors are expensive to fix once they propagate to finance, procurement, or sales documents; MDG's governance model is built specifically to intercept bad or unauthorized changes before they become 'active' data usable in other processes. Conceptually, a CR is not just a workflow wrapper. It is a business object instance built on the Business Object Processing Framework (BOPF) that holds staged (inactive) data alongside the current active data. When a data steward or requester enters changes, those changes are recorded against the CR's staging area, not the active area. Only when the CR completes its lifecycle successfully (passes validations, duplicate checks if configured, and required approval steps) does the system activate the data, copying it from staging into the active area which is then visible to consuming applications and, where configured, replicated to connected systems. Each CR is associated with a Change Request Type, which is configuration that determines: which business object/entity types can be processed, which change type is allowed (create, change, delete, or a combination), what workflow template governs approval routing, which processor tabs and UI configuration are shown to users, and what business activities and field-level authorizations apply. Without a properly configured CR type, users cannot even initiate the intended kind of change, so understanding CR types is foundational before touching workflow or validation configuration. The CR lifecycle generally moves through statuses such as 'in process', 'to be approved' (or similar review status), 'approved', and 'completed', with 'rejected' or 'withdrawn' as exit paths. Status is not simply a UI label; it drives which validations run, whether the record is locked from other CRs, and whether the workflow step is currently waiting on an agent. Locking matters in real projects: while a governed object instance is inside an open CR, MDG typically prevents other users from opening a conflicting CR for the same object, which avoids two people editing the same material or business partner simultaneously and causing a merge conflict at activation. From a business perspective, CRs give organizations an audit trail: who requested a change, who approved it, what the data looked like before and after, and when it became active. This is valuable for compliance, especially in regulated industries where master data changes (like vendor bank details) require segregation of duties between requester and approver. A beginner should internalize that MDG's value proposition is largely delivered through this CR-and-workflow mechanism, not through validations alone; validations and duplicate checks are quality gates that plug into the CR process, but the CR itself is the vehicle. It is also important to distinguish deployment contexts early. In S/4HANA on-premise and private cloud, CR configuration is highly flexible through IMG customizing, and process modeling is done with tools like the CR type and workflow configuration transactions. In S/4HANA Public Cloud editions of MDG-style governance, configuration options are typically more restricted to predefined, SAP-delivered scenarios with limited extensibility, so architects should not assume identical flexibility across editions. Where uncertain about specific public cloud restrictions, treat them as scenario-dependent and verify against the current release scope rather than assuming parity with on-premise. Recommended practices: • Design CR types around clear business scenarios (create, change, mark-for-deletion) rather than one catch-all type • Document which fields and business objects each CR type governs so stewards and approvers understand scope • Educate business users early that data is not 'live' until CR completion, to avoid confusion about why a change is not yet visible • Confirm governance flexibility and CR type restrictions specific to your deployment edition before designing complex scenarios Common mistakes to challenge: • Assuming a Change Request is just a UI wrapper for a workflow task rather than a staging container tied to a BOPF-based object model • Creating a single generic CR type for all change scenarios instead of separating create, change, and deletion flows, which complicates validation and workflow logic later • Not accounting for object locking behavior, leading to confusion when a second user cannot open a CR for a record already in process • Assuming CR configuration flexibility is identical across on-premise, private cloud, and public cloud editions of MDG • Overlooking that data onl

A consumer goods company implementing MDG for material master governance found that plant buyers were directly changing purchasing views in the ERP backend, causing inconsistent valuation classes across plants. The governance team introduced a 'Material Change' CR type restricted to changes on purchasing and accounting views, routed through a two-step workflow: a regional data steward review, then a finance approval step for valuation-relevant fields. Buyers could still request changes through a simplified UI, but nothing reached the active material master without passing through the CR lifecycle, giving finance visibility and control they previously lacked. A global consumer goods company using MDG for material governance noticed that roughly 5% of change requests for a specific plant region were sitting untouched for days with no visible approver. Investigation showed that a recent reorganization had removed a data steward's plant assignment without updating the agent determination rule's organizational data, so the rule returned no valid agent for that region and the work item defaulted to an unmonitored fallback queue. The fix involved updating the organizational assignment and adding a monitoring report to flag change requests with no assigned agent after a defined threshold, which became a standing production support check. A retail company implementing MDG for material master governance found that store managers were used to editing materials directly in the legacy system. During UAT, several managers were confused why they could not simply change a price group field on the material record. The consulting team ran a short enablement session showing that every change, including a single field like price group, must go through a Change Request, even if that CR type was configured with only one approval step. This resolved the confusion and also surfaced a real requirement: the client wanted certain low-risk fields to skip a second approver, which led to defining a lightweight CR type specifically for minor attribute changes. 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

First understand the current business requirement, dependencies, configuration or code path, integrations, production usage, and known pain points. Do not redesign before establishing the existing behavior. Lesson areas to review: Change Request Runtime Flow: Status Management, Agent Determination, and Troubleshooting Stuck Requests; Change Request Types, Steps, and Core Configuration Building Blocks; Configuring Change Request Types and Linking Workflow for Processing; Configuring Workflow Steps and Agent Determination for Change Requests; Understanding the Role of Change Requests in MDG Governance; What a Change Request Is and Why MDG Uses It Known 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 • Assuming a 'simple' change can bypass the CR mechanism entirely instead of using a lightweight CR type with minimal steps. • Confusing the staging (proposed) data shown inside an open CR with the active, already-governed master data. • Not checking the CR status and workflow log first when a user reports 'my change did not save,' leading to wasted troubleshooting time. • Expecting the same CR type configuration options to be available in a public cloud tenant as in an on-premise system. • Treating CR terminology as one-size-fits-all across every governed domain without confirming which entity types a given CR type actually supports. • Assuming a Change Request is just a UI wrapper for a workflow task rather than a staging container tied to a BOPF-based object model • Creating a single generic CR type for all change scenarios instead of separating create, change, and deletion flows, which complicates validation and workflow logic later • Not accounting for object locking behavior, leading to confusion when a second user cannot open a CR for a record already in process • Assuming CR configuration flexibility is identical across on-premise, private cloud, and public cloud editions of MDG • Overlooking that data only becomes active and consumable by other systems after

Explains how CR types are configured with entity types, processes, and workflow steps, and how these building blocks combine to control what a requester sees and who must approve. Deep explanation: Once a consultant understands that every governed change flows through a Change Request, the next layer is understanding how a CR type is actually assembled from configuration building blocks, because this is where most functional design decisions live. A CR type is not a single setting; it is a combination of several configured pieces that together determine the requester's experience, the validations that run, and the approval path. First, a CR type is linked to one or more governed entity types (such as Business Partner roles, Customer, Supplier, Material, or a custom entity depending on the domain model in use). This link determines which UI screens and field groups are relevant when someone creates a CR of that type. A CR type scoped only to 'Customer - Sales Area Data' will present a different set of screens than one scoped to full customer creation including general data, company code data, and sales area data. Second, a CR type is associated with a process, which in turn defines the sequence of workflow steps the CR will travel through. A process might be as simple as: requester enters data, system validates, data is activated automatically. Or it might include multiple steps: requester enters data, a data steward reviews and can send it back for correction, a specialist approver checks compliance-sensitive fields, and only then does the CR complete and activate. Each step can be associated with agent determination rules that decide who is presented the task in their inbox, and with rule-based checks that run at defined points in the process, such as before a step is completed or before the CR is finally activated. Third, within a CR, the concept of a 'change document' or field-level change list matters: because the system knows the before-and-after value of every field touched inside the CR, it can display a delta view during approval so reviewers see exactly what changed rather than having to compare the whole record manually. This delta view is a major usability feature and should be pointed out during training, because approvers who understand it review changes far faster and more accurately. A key intermediate-level design decision is choosing the granularity of CR types: too few CR types force every kind of change (creation, minor attribute update, deletion) through the same heavyweight approval chain, frustrating business users and increasing cycle time. Too many CR types create maintenance overhead and confuse requesters who are unsure which type to pick. A common, practical pattern is to define a small set of CR types aligned to business processes, such as one for full creation, one for minor attribute changes, one for blocking or marking for deletion, and possibly domain-specific ones for compliance-sensitive changes like bank data or tax classification, which usually route through a dedicated compliance approval step. Regarding deployment differences: in on-premise and private cloud S/4HANA, project teams typically have direct access to configure CR types, processes, and workflow step sequences, and can extend agent determination logic. In public cloud editions, the governance scenarios are often delivered with fixed or lightly adjustable process templates, and deep changes to the step sequence may not be possible or may require different extension mechanisms; teams should validate current capabilities in their specific tenant rather than assuming on-premise flexibility applies. Regardless of deployment, troubleshooting a 'stuck' CR always starts by identifying its CR type, its current step, the assigned agent, and any pending rule-based check failures, since these four facts explain almost every real-world CR support incident. Recommended practices: • Design CR types around business change scenarios, not just technical entity structures. • Keep a documented decision log explaining why each CR type exists and which fields or roles it covers. • Use delta/change views in approval steps and train reviewers to rely on them rather than manual comparison. • Validate agent determination rules whenever a workflow step is added or changed, before go-live. • Confirm current process and step configuration flexibility for the specific S/4HANA deployment (on-premise, private cloud, or public cloud) before finalizing design commitments. Common mistakes to challenge: • Defining only one CR type for all scenarios, forcing trivial changes through heavy multi-step approval. • Creating excessive numbers of narrow CR types that confuse requesters about which one to select. • Overlooking that changing the entity type scope of a CR type changes which UI fields appear, causing unexpected screen behavior after configuration changes. • Forgetting to review agent determination rules when a new workflow step is added, leaving tasks undeliverable to any inbox. • Assuming public cloud tenants allow the same depth of process and step configuration as on-premise systems. Interview angle: Interview questions at t

Learn how MDG change request types are linked to workflow templates, how processing steps are sequenced, and how agent determination rules assign the correct approvers and processors at each step. Deep 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. Recommended 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 • Configur

Explains how to configure Change Request types, associate them with workflow templates, and understand the runtime processing flow from creation through approval and activation. Deep 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. Recommended 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 Common mistakes to challenge: • 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, duplicat

Understand how a change request moves through its lifecycle at runtime, how agents are determined for each workflow step, and how to diagnose and resolve requests that get stuck, skip steps, or fail to route correctly in production. Deep explanation: Once a change request type and its associated workflow are configured, the real governance value of MDG shows up at runtime: how a request actually flows from creation through validation, approval, and activation, and what happens when that flow breaks. This lesson focuses on that operational layer, which is where most production support effort in MDG environments is spent. A change request instance carries a status that reflects where it sits in its lifecycle: typically something like created/in process, submitted for review, under approval, approved, rejected, or completed/activated. Each status transition is driven by workflow step completion, and the status itself controls what actions are available to a user (for example, whether the underlying master data can still be edited, whether it has moved to a read-only review state, or whether it is locked pending approval). Status values are not free-form; they are tied to the change request type configuration and to the workflow template that governs that type, so status meaning can differ slightly between change request types if the workflow design differs. Agent determination is the mechanism that decides who receives a given workflow step in their inbox. This can be based on organizational assignment (for example, a data steward responsible for a plant, company code, or business partner group), a fixed processor, a rule-based determination using attributes on the change request (such as region, data domain, or requester), or escalation logic that reassigns a step if it is not processed within a defined time. In real deployments, agent determination is one of the most common sources of process failure: if the rule returns no agent, or an agent who no longer has the right role, the work item may sit unclaimed, effectively stalling the request with no visible owner. At runtime, the typical document flow is: a requester creates a change request (manually, via a UI, or triggered by an interface/staging load), enters or changes governed attributes, and submits it. The workflow engine then evaluates the applicable process, generates work items for approval steps, and routes them based on agent determination. Approvers can approve, reject, or send back for correction; each action triggers a status change and may generate follow-up work items (for example, routing a rejected request back to the original requester). When all required approvals are complete, the system activates the data, meaning the change request's held or draft values are copied into the active master data, and any configured replication or distribution can then be triggered. Troubleshooting stuck requests usually starts with three questions: what is the current status of the change request, is there an open work item and who is it assigned to, and did the last workflow step actually complete or did it fail silently due to a rule or determination error. Common causes of stuck requests include: an agent determination rule that returns an empty result, a workflow condition step that cannot evaluate because an expected attribute is missing on the change request, a validation or duplicate-check failure that blocks progression without a clear user-facing message, or a technical workflow error (for example, a background step failing) that leaves the work item in an inconsistent state. Diagnosing these issues typically requires reviewing the workflow log for the specific change request, checking whether the relevant business rules or validations executed successfully, and confirming that the organizational or role assignments used by agent determination are still valid and unchanged. In S/4HANA on-premise and private cloud editions, support teams generally have direct access to workflow logs, rule trace tools, and the ability to manually intervene (for example, forwarding a work item or restarting a failed step) under change control. In S/4HANA Cloud Public Edition, the governance model is more restrictive: extensibility of workflow logic is limited to released options, and troubleshooting often depends more heavily on standard monitoring apps and, where necessary, engaging with the deployment's support channel rather than direct backend intervention. Architects should assume that public cloud troubleshooting capability will be narrower and should design agent determination and escalation rules conservatively to minimize the chance of unresolved dead-ends, since manual backend correction may not be an available fallback. Finally, activation and post-processing deserve attention: a completed change request does not guarantee downstream success. If replication to receiving systems is configured, activation only starts that process; replication itself can still fail independently for connectivity, mapping, or target-system validation reasons, and that failure is generally invisible from the change request status alone. Production support processes

Start by reproducing and scoping the issue, then validate the relevant master/configuration/runtime data and isolate the failing step before changing anything. Common failure patterns from the lesson set: • 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 • Assuming a 'simple' change can bypass the CR mechanism entirely instead of using a lightweight CR type with minimal steps. • Confusing the staging (proposed) data shown inside an open CR with the active, already-governed master data. • Not checking the CR status and workflow log first when a user reports 'my change did not save,' leading to wasted troubleshooting time. • Expecting the same CR type configuration options to be available in a public cloud tenant as in an on-premise system. • Treating CR terminology as one-size-fits-all across every governed domain without confirming which entity types a given CR type actually supports. • Assuming a Change Request is just a UI wrapper for a workflow task rather than a staging container tied to a BOPF-based object model • Creating a single generic CR type for all change scenarios instead of separating create, change, and deletion flows, which complicates validation and workflow logic later • Not accounting for object locking behavior, leading to confusion when a second user cannot open a CR for a record already in process • Assuming CR configuration flexibility is identical across on-premise, private cloud, and public cloud editions of MDG • Overlooking that data only becomes active and consumable by other systems after the CR completes, not at initial data entry • Assuming a change request status of 'completed' guarantees successful replication to receiving systems, when replication is a separate downstream process. • Not defining a fallback or default agent in agent determination rules, causing silent stalls when organizational data changes. • Overlooking that rejected requests routed back to the requester can also stall if the requester role or user is inactive. • Treating

• 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 • Always identify the CR type and current workflow step before diagnosing a reported data issue. • Educate business users early that all governed changes, however minor, go through a CR, to avoid adoption friction. • Keep a clear mapping of which CR types apply to which governed entities so support staff are not guessing. • Distinguish clearly in documentation and training between staging (in-process) data and active (published) data. • Confirm with the platform team whether the deployment is on-premise, private cloud, or public cloud before promising configuration changes to CR behavior. • Always separate 'change request status' checks from 'downstream replication status' checks during production support triage. • Build agent determination rules with an explicit fallback/default agent and log or alert when the fallback is used. • Periodically reconcile organizational assignments used in agent determination against current organizational structure to prevent drift. • Document status semantics per change request type so support staff do not assume uniform behavior across types. • In public cloud deployments, design workflows conservatively since manual backend correction options may be limited or unavailable. • Design CR types around business change scenarios, not just technical entity structures. • Keep a documented decision log explaining why each CR type exists and which fields or roles it covers. • Use delta/change views in approval steps and train reviewers to rely on them rather than manual comparison. • Validate agent determination rules whenever a workflow step is added or changed, before go-live. • Confirm current process and step configuration flexibility for the specific S/4HANA deployment (on-premise, private cloud, or public cloud) before finalizing design commitments. • Design CR types around clear business scenarios (create, change, mark-for-deletion) rather

Design change requests around business risk, parallel review and restartable workflow so governance stays controlled without creating unnecessary cycle time. Recommended design and operating practices: • Keep request types meaningful. • Use rules for agent determination. • Parallelize independent controls. • Support rework cleanly. • Monitor SLA and bottlenecks. Failure patterns that must be challenged: • Creating too many request types. • Hard-coding approvers. • Losing context after rejection. • Using serial approval where reviews are independent. • Measuring only completion, not turnaround. A strong architect answer should make the business or analytical semantics explicit, identify integration and security boundaries, define performance/volume assumptions, show monitoring and recovery ownership, and require test evidence for both the happy path and material failure paths before go-live.