Lesson 2 of 6
Change requests, steps and workflow
10 min
Listen to this lesson
In central governance, nothing changes the operational record directly. A user creates a change request: a container that holds the new or changed data, the reason, attachments and the history of everyone who touched it. The data waits in a staging area while the request moves through its workflow steps. Only when the last approval is given is the data activated, which means written to the active business partner, product or finance tables.
The building blocks
In MDG on SAP S/4HANA (classic mode), the usual workflow is the rule-based workflow, built on SAP Business Workflow. Its routing is not drawn in a workflow editor for each request type. Instead, it is defined in BRFplus decision tables, configured through the activity Configure Rule-Based Workflow (transaction USMD_SSW_RULE). For each change request type, a single-value decision table decides the next step and action from the current step and the user's decision; user-agent tables decide who receives the step; and a non-user-agent table defines background steps such as activation. SAP delivers example decision tables per change request type, and the change request type is linked to the rule-based workflow template WS60800086.
The change request lifecycle
Real status values and step numbers come from configuration, so read them from your system rather than from this diagram. Two behaviors are worth knowing. A rejected task usually goes back to the previous user, and a comment is mandatory by default. And header attachments are usually discarded at the end of the workflow unless the documents are stored in a document management system, so evidence such as a supplier's bank letter needs a deliberate storage decision.
Working with requests
| Who | Typical task | Where |
|---|---|---|
| Requester (Maria, Omar, Lucía) | Create a request, attach evidence, track status | The MDG business partner apps in the launchpad; My Change Requests app for status |
| Data steward (Hannah's team) | Complete data, fix validation errors, resolve duplicates | Workflow inbox, MDG processing UI |
| Approver (Dan for bank data) | Approve or reject with a comment | Workflow inbox or e-mail notification |
| Administrator | Check stuck requests and workflow errors | Workflow and change request monitoring tools |
Roles in a change request. App names vary by release and role; check your launchpad catalogs.
- 1. RequestOmar starts "Create Supplier" for Lakeside's new subsidiary, enters name, address, tax number and bank data, attaches the bank letter
- 2. CheckValidations run: tax number format, duplicate check against existing suppliers, required purchasing data
- 3. CompleteHannah's team adds purchasing organization 1710 data and the reconciliation account
- 4. ApproveBank data present, so the rules route an approval step to Dan
- 5. ActivateThe supplier is written to the active tables; the request is closed with its history
One record, many records
Change request types differ in how many records they carry. A single-object request holds one record with its sub-segments, such as a supplier with its company code and purchasing organization data. A multiple-record request uses table-style screens to change several records at once, and Customizing can cap the number of records, for example at 40 or 50. Very large changes belong in mass processing (lesson 3). Pick the type deliberately: a request that bundles 50 suppliers waits for the slowest approval, and one rejected record can hold up 49 good ones.
| Request scope | Good for | Watch out for |
|---|---|---|
| Single object | New customers and suppliers, bank data changes, blocks | Volume: many small requests for a reorganization |
| Multiple records | A small group of related changes, such as all ship-tos of one customer | One rejection holding up the whole request |
| Mass processing | Hundreds of records with the same kind of change | Validation results and statistics must be reviewed before activation |
Choosing the scope of a governed change.
What goes wrong in testing
| Pitfall | Consequence | Prevention |
|---|---|---|
| Only the happy path tested | Rejection and revision paths fail in production | Test every decision at every step at least once |
| Test users hold all roles | Agent determination never really tested | Use one test user per role, as in production |
| Activation not checked | Request shows complete, but the active record differs | Check the active business partner after every test |
| Attachments assumed to persist | Evidence lost after workflow end | Test where attachments end up and who can see them |
Typical change request test failures.
What would you do?
A supplier change request at Contoso has been "in process" for nine days. Nobody has a task in the inbox. Omar is asking why the supplier still cannot be used. What is the most likely cause to check first?
- A change request holds data in staging until approval; activation writes the operational record.
- Change request types, steps, agents and rules define the process.
- Rule-based workflow routes with BRFplus decision tables (USMD_SSW_RULE).
- Test rejection, revision and agent determination with real roles, not super-users.
Check your understanding · not graded
Lesson check
1. Where does data in an open change request live before approval?
2. How is routing defined in the MDG rule-based workflow?
3. An approver rejects a request. What usually happens by default?
4. Why prefer routing rules based on data values over rules based on requesters?