MM / P2Parchitect

MM Flexible Workflow Part 6: Coexistence with Classic Release and Approval Governance

Key takeaway

Govern approvals across the landscape: when classic release and flexible workflow coexist (by document type), transition plans, approval policy ownership, segregation of duties, audit evidence, KPIs, and alignment with Ariba or central procurement approvals.

Explanation

📌 KEY POINTS
✅ Coexistence is per document type: each type uses either classic release or flexible workflow.
✅ Approval policy (thresholds, approvers) is owned by the business/finance, implemented by process experts.
✅ Segregation of duties: requester ≠ approver; buyers don't approve their own POs.
✅ Audit: workflow logs, approval history, change of definitions tracked.
⚠️ Approvals duplicated in Ariba and S/4HANA create delays and conflicts — decide where approval happens.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 5 covered agents and troubleshooting. Now governance.

━━━━━━━━━━━━━━━━━━━━
▶ 1. COEXISTENCE

Transition by document type; no double logic.

━━━━━━━━━━━━━━━━━━━━
▶ 2. POLICY OWNERSHIP

Approval matrix owned by finance/procurement; change control for definitions.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SOD AND CONTROLS

Requester/approver separation; authorization for Manage Workflows.

━━━━━━━━━━━━━━━━━━━━
▶ 4. AUDIT AND KPIS

Approval history; cycle time; auto-release rate; rejected rate.

━━━━━━━━━━━━━━━━━━━━
▶ 5. LANDSCAPE

Ariba/central procurement approvals vs S/4HANA: one approval point per document.

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

Document the approval matrix.
Assign ownership and change control.
Define KPIs and audits.

✅ CHECKPOINT: each document type has one approval mechanism, an owner and KPIs.

Code example

ABAP Code

===== STEP 1: governance =====Approval matrix (owner: finance) → workflow definitions (maintained by process experts) → change log review quarterly ===== STEP 2: KPIs =====Median approval time | % auto-released | % rejected | high-value auto-releases (should be 0) ===== STEP 3: landscape =====Ariba requisitions approved in Ariba → S/4HANA PO without second approval (or exception-only)

Real project scenario

During a central procurement rollout, requisitions were approved in Ariba and again in S/4HANA, doubling cycle time and confusing approvers. The team defined Ariba as the approval point for requisitions and S/4HANA only for PO exceptions, with KPIs to confirm improvement.

Common mistakes

Duplicate approval points.
No policy owner.
Buyers approving own POs.
Undocumented definition changes.
No KPIs.

Best practices

One approval point per document.
Business-owned matrix.
Enforce SoD.
Audit definition changes.
Track KPIs.

Interview angle

Questions: "Can classic release and flexible workflow coexist?", "How do you govern approvals?", "Where should approvals happen with Ariba?"
Strong answer: per-type coexistence, policy ownership, SoD, audit and KPIs, single approval point across landscape.

Practice this lesson

Quick check

1. Who should own the approval matrix implemented in flexible workflow?

2. Requisitions are approved in Ariba and again in S/4HANA. What is the recommendation?

3. Which control supports segregation of duties in purchasing approvals?

Interview questions

1. When migrating open purchase orders that are part of a supplier onboarding flow requiring Flexible Workflow approval, what key architectural consideration must be addressed regarding workflow state during migration?

Answer it in your own words first, then compare.

2. During cutover to a Central Procurement hub landscape, business users report that purchase requisition approval workflows in the connected S/4HANA system are not triggering during hypercare, even though the same requisitions approved fine in pre-production testing. How do you approach root-causing this using Flexible Workflow?

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.