Introduction

A quick note before diving in: this blog was initially drafted with the help of SAP Joule for Consultants. — a great example of how AI tools can meaningfully accelerate the writing process.  And improved with Claude Sonnet. That said, all content, accuracy, and opinions here are entirely my own responsibility.

A special thank you to the colleagues who built and shipped these features under significant time pressure. Great software doesn’t happen without great teamwork — and it ultimately takes dedicated engineers to turn ideas into delivered, production-ready capabilities.

In today’s compliance-driven enterprise landscape, ensuring that critical business decisions are never made unilaterally is both a governance imperative and, in many industries, a regulatory requirement. Workflow automation has long been a cornerstone of SAP’s approach to streamlining approvals — but automation without embedded controls can introduce new risks rather than eliminate them.

Two foundational control mechanisms address this challenge directly:

• Multi-Processor Task Completion — ensuring that a defined number of independent individuals must each process a task before a workflow can continue
• Approver Exclusion (4-Eyes Principle) — ensuring that the person who created a business document cannot also approve it (for details on this capability, see the linked resource)

With SAP S/4HANA 2608 (and 2702 for customers on that release cycle), SAP has introduced both of these capabilities natively within the Manage Workflow application and the broader flexible workflow framework — empowering Business Process Experts to configure robust dual-control and multi-control approval processes without writing a single line of code.

But governance is only as strong as its weakest configuration. That is why this release also introduces a new Validation Callback method that prevents misconfigured workflow definitions from ever being activated — closing the gap between documentation-based guidance and system-enforced compliance.

This blog covers all three features comprehensively: what they are, why they were introduced, how they work, and how to configure them correctly.

Background & Motivation

The Governance Gap in Workflow Automation

Prior to these enhancements, the Manage Workflows application offered two task completion modes for workflow step recipients:

Mode Runtime Behavior Limitation

Neither mode offered the precision required for a true four-eyes or six-eyes principle. Organizations needing exactly two or three independent completions had to rely on the “run with previous” feature combined with manual process discipline or documentation-based guidance — all of which are fragile controls that do not scale in enterprise environments.

Multi-Processor Task Completion (4-Eyes / 6-Eyes via Configuration)

What Is It?

The Multi-Processor Task Completion feature addresses this gap directly: it ensures that a defined number of independent individuals each complete their own task instance before the workflow continues.

This is the mechanism that enables a true four-eyes principle (2 processors) or six-eyes principle (3 processors) in scenarios where multiple parallel approvers must each independently act — not just one of them, and not necessarily all of them.

Task Instance Behavior: The Three Modes

Completion mode is configured in the Recipients section of a workflow step using a radio button group:

Mode Runtime Behavior

The two or three recipients option is the key addition in releases 2608/2702. It fills the gap between “one person acts” and “everyone must act” — enabling precise control over how many independent completions are required before the workflow proceeds.

Recipient Assignment Types

The recipient configuration UI is used consistently across steps, notifications, and other workflow artifacts. Supported assignment types include:

• Agent Rule — dynamically resolves recipients based on business rules
• Team — assigns the task to a predefined team (configured via Manage Teams and Responsibilities)
• Concrete User — directly specifies one or more named users

Note: If you select the two or three recipients mode but assign only one concrete user, the system will display a validation error.

 Runtime Design

Several new UI elements have been introduced to support transparency at runtime:

• A status bar at the task instance level shows who is currently processing a task within a team — and clearly indicates who has already approved.

The Uniqueness Rule: One Person, One Completion

A critical safeguard of this feature is that the same person cannot complete more than one parallel task instance. This is what makes the four-eyes and six-eyes principles meaningful — it is not sufficient for two task instances to exist; they must be completed by two different people.

This uniqueness rule applies even in edge cases involving substitution and forwarding:

Scenario Behavior

Resolution for blocked users: If a person is unable to complete their own task because the uniqueness rule applies (e.g., they already acted via substitution on a parallel instance), they can — where permitted — forward their own task instance to another eligible person. This self-service resolution requires no administrative intervention.

An explicit error message is displayed when a user attempts to complete a second task instance in violation of this rule.

Validation Callback for Mandatory Step Configurations

The Problem It Solves

The introduction of the N-processor option increases the risk that a workflow modeler will inadvertently misconfigure a step that must always be set to “All of the recipients.” The “Verify Intercompany General Journal Entry” step is the primary example — but the pattern applies to any scenario where a specific completion mode is a non-negotiable compliance requirement.

Previously, this requirement was enforced only through documentation. With the 2608 release, a validation callback mechanism now prevents the activation of a workflow definition if a mandatory step is incorrectly configured — catching errors before they affect live business processes.

How the Validation Works

The validation is implemented via the if_swf_flex_ifs_def_appl~on_validation_callback method. When a workflow modeler attempts to activate a workflow definition, the system executes this callback. If the VerifyMultiInstance step is not configured to require all processors (cv_all_processors), the system raises a validation exception and blocks activation.

This represents a significant improvement over documentation-only guidance:

• It operates at activation time, not at runtime — catching errors before they affect live processes
• It is automatic and non-bypassable — a modeler cannot accidentally skip the validation
• It provides a clear error message directing the modeler to correct the configuration
• It scales — the same pattern can be applied to any scenario where specific configurations are mandatory

Code Reference (Baseline for Implementation)

The following ABAP snippet serves as a baseline for implementing the validation callback:

METHOD if_swf_flex_ifs_def_appl~on_validation_callback.  
DATA(lt_activity) = io_workflow->get_all_activities( ).  
" Raise a validation error if the multi-instance step is not configured to require all processors.  
LOOP AT lt_activity INTO DATA(lo_activity).    
IF lo_activity->get_step_id( ) = 'VerifyMultiInstance'.      
DATA(lv_number_of_proc) = lo_activity->get_number_of_requ_processors( ).      
IF lv_number_of_proc <> lo_activity->cv_all_processors.        
RAISE EXCEPTION TYPE cx_swf_flex_ifs_exception          
MESSAGE ID 'Your Message Class'
TYPE 'E'          
NUMBER 'Your Message Number'.      
ENDIF.    
ENDIF.  
ENDLOOP.
ENDMETHOD.

Scope and Intentional Boundaries

It is important to understand the deliberate scope boundaries of this feature:

In Scope Out of Scope

Discussions are already underway to explore UX improvements that would disable invalid options directly in the configuration interface.

Combined Use & Real-World Scenarios

When to Use Which Feature

Understanding when to apply each feature — and how they complement each other — is key to designing effective compliance-oriented workflows:

Requirement Recommended Feature

In many real-world scenarios, all three features will be active simultaneously — delivering layered, system-enforced governance across the full approval lifecycle.

Example: Financial Processes — Journal Entry Postings

For multi-level verification scenarios — such as a 4-level approval hierarchy based on distinct monetary thresholds across multiple company codes — workflows can be defined with sequentially ordered steps, each with its own amount-based precondition and assigned approver group. The multi-processor task completion feature ensures that each level of that hierarchy meets the required independent review count.

Configuration Checklist & Getting Started

Prerequisites and System Requirements

• SAP S/4HANA 2608 (on-premise) or 2702 (for customers on that release cycle)
• Flexible Workflow must be active and configured for the relevant business object
• Users must be set up as business users with appropriate authorizations
• The Manage Teams and Responsibilities application is recommended for agent determination
• For scenario developers: the Validation Callback is implemented via the on_validation_callback method

Best Practices

• Always test your workflow configuration using the Simulation feature (available from SAP S/4HANA Cloud 2408 onwards) — verify which workflow definition triggers for a given business object instance before going live
• Explicitly configure excluded agents to avoid workflow stalls or compliance gaps when the initiator is the only eligible approver
• Define clear preconditions for each step in multi-step scenarios to avoid unintended overlaps in approval routing