Configuring and Running Mass Change Requests: Selection, Field Rules, and Workflow Routing

Explanation

Configuring mass processing in SAP MDG involves several layers that a consultant must understand together, because a misconfiguration in one layer can silently affect the others. The first layer is the search and selection mechanism that builds the worklist of candidate objects. This typically relies on the same search infrastructure used for single-object governance (attribute-based search over active or governance data), so consultants should ensure the relevant search connector or search model is correctly indexed and includes the fields needed for filtering, such as organizational assignments, classification values, or status flags. If the search index is stale or missing key fields, stewards may build an incomplete or inaccurate worklist without realizing it. The second layer is the mass change definition itself: which fields are eligible for mass update, and what values or rules apply. In most MDG configurations, mass processing UIs are configured per object type (material, business partner, custom object) and expose a curated subset of fields considered safe for bulk editing - typically classification, organizational, or status attributes rather than deeply structural identifiers. Consultants configuring this need to align with data governance policy on which fields should never be mass-changed (for example, key structural identifiers that trigger downstream re-numbering) versus which are safe (for example, a purchasing group or a marketing attribute). This is usually controlled through configuration of the mass processing UI/BDT-style structures or the relevant Fiori mass change app configuration, depending on release; consultants should confirm the exact configuration path in their specific SAP MDG version rather than assuming an ECC-era transaction path applies unchanged in S/4HANA. The third layer is change request grouping and creation. When a mass action is submitted, the system must decide how to bundle the selected objects into one or more change requests. Common patterns include: one change request per selected object (safest for granular approval, but creates high workflow volume), one change request containing the entire selected population (simplest for the steward, but risky if a single validation failure or workflow rejection blocks the entire batch), or grouping by a business criterion such as object type, region, or company code (a balance that many production designs favor). The grouping strategy should be agreed upon with business process owners before go-live, because it directly shapes how approvers experience their inbox and how failures are isolated. The fourth layer is validation and duplicate check execution during mass processing. Because these checks run per object (or per relevant grouping), performance becomes a real constraint at scale: a validation rule that is cheap for one record can become expensive across ten thousand, especially if it involves database lookups or external service calls (for example, third-party duplicate check services). Consultants should test mass runs against realistic data volumes in a quality/performance environment before production cutover, and review whether validations can run in background/asynchronous mode versus blocking the UI. Finally, workflow routing for mass change requests generally reuses the same workflow templates as single-object governance, meaning task determination, agent determination, and escalation rules apply unchanged. The practical difference is volume: an agent determination rule based on individual record ownership may not scale well when thousands of objects with different owners are bundled into fewer change requests, so many designs assign mass-created change requests to a dedicated steward role rather than per-record owners. Differences exist between deployment types: on-premise and private cloud editions typically allow more customization of grouping logic and workflow determination for mass scenarios, while public cloud editions tend to provide fixed, standardized behavior aligned to delivered business roles, and any deviation should be checked against the current release scope rather than assumed configurable.

Code example

* Illustrative BAdI-style pseudocode for grouping objects into change requests during mass processing.* This is a conceptual illustration only - exact BAdI/interface names vary by MDG version and object type* and must be confirmed in the relevant system's implementation guide before use. METHOD determine_change_request_grouping.  " Input: internal table of selected objects with key fields (object_id, company_code, region)  " Goal: group selected objects into logical change request buckets by company_code  " instead of one giant change request, to keep approver workload manageable.   LOOP AT it_selected_objects INTO ls_object.    READ TABLE it_grouping_buckets WITH KEY company_code = ls_object-company_code         INTO ls_bucket.    IF sy-subrc <> 0.      " create a new bucket keyed by company code      ls_bucket-company_code = ls_object-company_code.      APPEND ls_bucket TO it_grouping_buckets.    ENDIF.    APPEND ls_object TO ls_bucket-objects.    MODIFY it_grouping_buckets FROM ls_bucket           TRANSPORTING objects           WHERE company_code = ls_object-company_code.  ENDLOOP.   " Each bucket in it_grouping_buckets becomes one change request,  " so approvers only review objects relevant to their company code.ENDMETHOD.

Real project scenario

A chemical manufacturer needs to update the profit center on 8,000 finished-goods materials following an internal reorganization. The project team decides against a single mega change request because the initial performance test in the quality system showed validation checks (which call an internal costing lookup) taking noticeably longer as batch size grew, and a single failure anywhere in the batch would have blocked the entire population from activating. Instead, the team configures grouping by plant, producing around 40 smaller change requests, each routed to the relevant plant controller for approval. This let two plants activate their changes on schedule while a data issue in a third plant was resolved separately without holding up the others.

Common mistakes

• Bundling an entire mass selection into one giant change request without considering that a single validation failure can block the whole population • Not testing mass validation and duplicate check performance against realistic data volumes before production cutover • Assuming per-object workflow agent determination rules will scale cleanly to mass scenarios without review • Exposing structurally sensitive fields for mass change without governance sign-off, risking large-scale data integrity issues • Assuming on-premise mass processing configuration options are identical in SAP MDG public cloud without checking current release scope

Best practices

• Agree on change request grouping strategy with business process owners before configuring mass processing • Restrict mass-editable fields to those approved by data governance policy, avoiding structurally sensitive identifiers • Performance-test mass validations and duplicate checks against production-like data volumes before go-live • Route mass-created change requests to dedicated steward roles rather than relying on per-record owner determination at scale • Confirm mass processing configuration options against the specific SAP MDG deployment and release before designing the solution

Interview angle

Expect scenario-based questions about how you would design change request grouping for a large bulk update, and how you would balance approver reviewability against processing simplicity. Strong answers reference performance testing, grouping strategy trade-offs, and awareness that workflow templates are typically reused rather than rebuilt for mass scenarios.