Configuring Change Request Types and Workflow for Material Governance

Explanation

Once the foundational data model concepts are understood, the next practical skill is configuring change request types and their associated workflow for material governance. This is where a consultant translates business requirements (who can request what, who must approve it, what data must be complete before approval) into concrete MDG process configuration. A change request type is the configuration object that ties together: the business activity it supports (create, change, mark for deletion, extend to new plant/org level), the entity types it can carry, the applicable workflow, and the number range or processing behavior for the resulting change request. When designing change request types for material governance, a common project pattern is to separate simple attribute changes (e.g., updating a description or purchasing text) from structural changes (e.g., creating a brand-new material or extending it to new plants), because these usually warrant different approval intensity. Workflow design considerations: 1. Single-step vs multi-step approval: Simple, low-risk changes can be configured to auto-complete without human approval steps if validation rules pass, while material creation or valuation-relevant changes typically route to one or more approval steps. Workflow steps are usually associated with agents or roles, such as a data steward, plant-specific master data coordinator, or finance approver for valuation-relevant fields. 2. Rule-based agent determination versus fixed agents: Larger organizations benefit from rule-based agent determination that routes work items based on material type, plant, or requesting business unit, rather than hardcoding a single approver, because fixed agents quickly become a bottleneck and a single point of failure. 3. Parallel vs sequential steps: When multiple functional reviewers must weigh in (e.g., purchasing and quality both need to review a new material), workflow can be designed with parallel review steps that converge before final activation, reducing overall cycle time compared to a purely sequential chain. 4. Validation integration into workflow: Before a work item reaches a human approver, validation rules should already have run so that obviously incomplete or non-compliant requests are rejected or sent back automatically, preserving approver time for genuine business judgment calls rather than catching missing mandatory fields. 5. Status and completion handling: Each change request type has a defined lifecycle of statuses (e.g., in process, in review, approved, completed, rejected). Configuration determines what actions are permitted in each status and which user or role can transition the request, and this must align with the organization's segregation-of-duties requirements — for example, ensuring the same person cannot both create and approve a material change. Runtime and integration flow: when a user creates a change request through the governance UI, the system stages the requested changes, triggers configured validation and derivation rules, and then creates workflow items for the next required approver(s) based on the configured agent determination. As each step completes, the change request status advances; once the final approval step passes, the request is completed, moving the data into the active area, from which replication (covered in later governance rules and replication lessons) can then take place. Troubleshooting patterns: a very common intermediate-level issue is a change request that appears stuck 'in process' with no visible work item, which is often traced to an agent determination rule that resolved to no valid agent, or to a workflow configuration mismatch between the business activity and change request type. Another frequent issue is validation rules firing inconsistently, which is often a sign that rule scoping (which entity, which business activity) was not restricted correctly, causing rules meant for 'change' to also fire on 'create' unexpectedly. Across S/4HANA on-premise and private cloud, change request type and workflow configuration is typically performed through the governance configuration environment with reasonably deep flexibility. In public cloud or more restricted deployment models, workflow customization options may be more limited or delivered through predefined content, so consultants should validate actual configurability with the specific project team rather than assuming full on-premise-level flexibility is available.

Code example

Conceptual configuration outline for a material change request type (illustrative, not a literal transaction reference): Change Request Type: MAT_CREATE_STD  Business Activity: Create Material  Entities in scope: Material Header, Plant Data, Sales Data, Purchasing Data  Workflow Template: MAT_CREATE_APPROVAL    Step 1: Automatic Validation (mandatory fields, duplicate check)      -> On failure: return to requester with error list      -> On success: proceed to Step 2    Step 2: Data Steward Review (rule-based agent by material type)      -> Approve: proceed to Step 3      -> Reject: return to requester with comments    Step 3: Finance Review (only if valuation-relevant fields changed)      -> Approve: complete change request, activate data      -> Reject: return to Step 2 Change Request Type: MAT_CHANGE_MINOR  Business Activity: Change Material (non-valuation fields)  Workflow Template: MAT_CHANGE_AUTO    Step 1: Automatic Validation only      -> On success: auto-complete, no human approval required

Real project scenario

During an S/4HANA MDG rollout, the project team initially configured a single change request type for all material creates and changes, routing everything through the same two-step approval. Business users complained that trivial text corrections took days to approve because they queued behind full material creation reviews. The team redesigned the process into a lightweight change request type for minor non-valuation edits with only automatic validation, and a full multi-step approval type for creation and valuation-relevant changes, which significantly reduced average cycle time for routine edits while keeping strict control over higher-risk changes.

Common mistakes

• Using a single change request type and workflow for both trivial edits and full material creation, causing unnecessary approval delays. • Hardcoding a single fixed approver instead of rule-based agent determination, creating a bottleneck when that person is unavailable. • Allowing the same user role to both create and give final approval on a change request, violating segregation-of-duties expectations. • Not restricting validation rule scope to the correct business activity, causing rules intended only for changes to also block valid new material creation. • Assuming workflow configuration flexibility is identical across every SAP deployment option without confirming with the project's technical team.

Best practices

• Design at least two change request type tiers: lightweight for low-risk edits and full multi-step approval for creation or valuation-relevant changes. • Use rule-based agent determination keyed on material type, plant, or business unit instead of fixed named approvers. • Run automatic validations before any human workflow step to protect approver time. • Enforce segregation of duties by ensuring requesters cannot also be final approvers on the same change request. • Document the full status lifecycle and who can act at each status to support audit and troubleshooting later.

Interview angle

Expect scenario-based questions such as 'how would you design approval workflow for material creation versus a minor text change' or 'how do you prevent a single approver bottleneck.' Strong answers reference rule-based agent determination, differentiated change request types by risk level, and segregation-of-duties controls rather than a one-size-fits-all workflow.