MM / P2Pintermediate

MM Flexible Workflow Part 3: Start Conditions, Approval Steps, Recipients and Workflow Order

Key takeaway

Design workflow definitions: start conditions (amount, company code, purchasing group, material group, account assignment), sequential steps with step conditions, recipients by role or user, exception handling (reject, rework), and the order of workflows when several match.

Explanation

📌 KEY POINTS
✅ Start conditions decide whether a workflow applies (e.g. amount > 10,000 and company code 1000).
✅ Steps run sequentially; each step can have its own condition and recipients.
✅ Recipients: roles (e.g. manager of cost center, purchasing group responsible) preferred over users.
✅ Only one workflow runs per document: the first matching workflow in the defined order.
⚠️ A broad workflow placed first can hide more specific ones.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 covered architecture. Now designing definitions.

━━━━━━━━━━━━━━━━━━━━
▶ 1. START CONDITIONS

Amounts, organizational units, document types, categories.

━━━━━━━━━━━━━━━━━━━━
▶ 2. STEPS

Sequential steps; step conditions (e.g. only if > 100,000).

━━━━━━━━━━━━━━━━━━━━
▶ 3. RECIPIENTS

Roles via teams and responsibilities; user as fallback.

━━━━━━━━━━━━━━━━━━━━
▶ 4. EXCEPTIONS

Reject behavior, rework, resubmission after change.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ORDER

Workflows sorted; specific before generic; catch-all last.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Create specific workflow (capex > 50k) and generic (all > 10k).
Order specific first.
Test documents in each band.

✅ CHECKPOINT: every document triggers the intended workflow.

Code example

ABAP Code

===== STEP 1: definitions =====WF1 "Capex > 50k": conditions account assignment A, amount > 50,000 → step 1 asset manager, step 2 finance directorWF2 "All > 10k": amount > 10,000 → step 1 purchasing group lead ===== STEP 2: order =====1. WF1 | 2. WF2 | (no match → auto-release) ===== STEP 3: recipients =====Manage Teams and Responsibilities: team per purchasing group with function "approver"

Real project scenario

Two active PO workflows both matched company code 1000; the generic one was first, so capex approvals never reached the asset manager. Reordering specific workflows first and adding a design rule (specific before generic) fixed routing.

Common mistakes

Generic workflows first.
Overlapping conditions.
User-based recipients.
No step conditions.
Not testing each band.

Best practices

Order specific to generic.
Keep conditions clear.
Use teams/roles.
Document design.
Test systematically.

Interview angle

Questions: "How is a workflow chosen when several match?", "How are recipients determined?", "What are step conditions?"
Strong answer: start conditions, sequential steps with conditions, role-based recipients, exception handling, first matching workflow order.

Practice this lesson

Quick check

1. Which decision option in a Flexible Workflow approval step lets an approver dynamically insert an additional approver into the process, without changing the underlying BRFplus configuration?

2. A company wants a purchase order to require two sequential approval levels only when the PO net value exceeds a defined threshold, and no approval otherwise. Which Flexible Workflow feature enables this logic?

3. Two PO workflows match the same document. Which one runs?

Interview questions

1. For a service PO requiring multi-level approval, the business wants a flexible workflow with dynamic step insertion (e.g., add an extra approver above $50,000) plus automatic email output to the vendor upon final approval. How would you design this integration in S/4HANA?

Answer it in your own words first, then compare.

2. Design flexible workflows for POs: capex POs need asset manager and finance approval, other POs above 10k need the purchasing group lead.

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.