Lesson 3 of 6
Recipients, changes and rework
7 min
A workflow is only as good as its routing. The start conditions decide whether a PO is approved; the recipients decide who approves it; and the change and rework rules decide what happens when the document moves after approval. This lesson covers the design decisions that cause the most defects in practice.
Choosing recipients
A step's recipients can be named users, but that breaks the first time someone changes jobs. Better options are roles that SAP resolves at runtime, such as the manager of the document creator or the manager of the last approver, and teams maintained in the Manage Teams and Responsibilities app, where functions (for example "purchasing manager") are assigned to people for a scope such as purchasing group or plant. Manager-based roles only work if manager relationships are maintained for the users; check where your system gets them before relying on them.
| Recipient type | Contoso use | Risk |
|---|---|---|
| Named user | None in production | Breaks when people leave or change roles |
| Manager of the creator | Self-service requisitions | Needs maintained manager relationships |
| Manager of the last approver | Escalation in multi-step approvals | Same; plus long chains |
| Team function (responsibility management) | Purchasing manager per plant; plant controller per plant | Team data must be maintained like master data |
Recipient options and what can go wrong.
- PO saved$150,000, plant 1710, purchasing group 001
- Definition"PO 100k and above" starts
- Step 1 recipientsTeam function "purchasing manager" for plant 1710 resolves to two people
- Step 1 approvalFirst to act approves; the item leaves the other inbox
- Step 2 recipientsTeam function "plant controller" for plant 1710
- ReleasedBoth steps approved; PO output to Lakeside
Changes after approval
POs change: quantities rise, prices are renegotiated. By default, a change to the PO's total value restarts the approval, so an approved $30,000 PO raised to $90,000 goes back for approval. Whether other changes restart the workflow can be adjusted (through a configuration option or a BAdI, depending on edition). Contoso's rule: any increase in value restarts; decreases and date changes do not. That rule must be tested in both directions.
- MonApproved$30,000 PO approved by the purchasing manager and output
- WedChangedBuyer raises quantity; value now $90,000
- WedRestartedWorkflow restarts; PO back to "in approval"; change output held
- ThuRe-approvedPurchasing manager approves the new value
- ThuChange outputLakeside receives the changed PO
Reject or rework?
A rejection ends the approval: the document is rejected and must be handled by its creator (corrected and resubmitted, or deleted, depending on the document). Some scenarios also support rework: the approver sends the document back to the creator with a comment, the creator fixes it, and the workflow continues, repeats the step or restarts, as configured. Rework needs its own step type and exception handling settings, and some rework functions cannot be switched off once activated, so treat them as a design decision for the process owner.
Notifications and deadlines complete the design. Decide whether the buyer gets an email when a PO is rejected, whether approvers get reminders, and what happens when an item sits unapproved for days. Not every option exists for every scenario and release, so check what the flexible workflow apps in your system offer before promising it to the business. Whatever is chosen, write it into the design document next to the thresholds, because testers need it to define expected results.
What would you do?
An approved $30,000 PO is reduced to $28,000 because Lakeside offered a discount. The buyer complains that the PO went back for approval. Contoso's rule says decreases should not restart. What should happen?
- Prefer roles and team functions over named users as recipients.
- Manager-based roles need maintained manager relationships; team functions need maintained team data.
- A total value change restarts PO approval by default; agree and test which changes restart.
- Rejection ends the approval; rework returns the document for correction under configured rules.
Check your understanding · not graded
Lesson check
1. Why avoid named users as workflow recipients?
2. Which app maintains team functions used as recipients?
3. By default, which PO change restarts approval?
4. What prerequisite do manager-based recipient roles have?