Change Request Types, Steps, and Core Configuration Building Blocks
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.
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.
Real project scenario
During a private cloud S/4HANA rollout for supplier master governance, the business wanted a fast path for updating a supplier's phone number without going through the same three-level approval used for new supplier creation with banking details. The design team created a dedicated CR type scoped to general contact data only, attached to a short process with a single confirmation step, while keeping the original heavyweight CR type for creation and bank data changes. This reduced average cycle time for minor updates from two days to under an hour and significantly improved business adoption.
Common mistakes
• 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.
Best 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.
Interview angle
Interview questions at this level often probe whether a candidate can explain the relationship between CR type, entity type, process, and workflow steps, and whether they can justify a CR type design decision such as splitting minor changes from full creation. Candidates should be ready to explain the trade-off between too few CR types (slow, frustrating heavy approval for small changes) and too many (maintenance burden, requester confusion), and should mention delta/change-document views as a reviewer efficiency feature.