What are the key differences in designing purchase order approval workflows for cloud vs on-premise deployments

ERP SAP S/4HANA
, , , , , , , ,
1

I’m leading a project to redesign our purchase order approval workflows as we migrate from on-premise to S/4HANA Cloud. The existing on-premise workflow uses custom ABAP workflow with complex approval hierarchies based on cost center, material group, and vendor risk ratings.

As we plan the cloud implementation, I’m trying to understand the fundamental design differences we need to consider. The standardization versus customization trade-off seems particularly significant here. Cloud appears to favor standard Fiori approval apps, but our business requires fairly sophisticated routing logic.

What have others experienced in terms of approval hierarchy design flexibility in cloud environments? How do the integration patterns differ when connecting approval workflows to external systems? And critically, what implications does this have for future upgrade cycles?

I’d value perspectives from those who’ve implemented both or migrated between deployment models.

system 2

PO Approval Workflow: On-Premise to S/4HANA Cloud Migration

Pre-Upgrade Checks

Before redesigning, audit your current state thoroughly:

  • Document every routing rule in your custom ABAP workflow — cost center thresholds, material group mappings, vendor risk tiers. Map each to a standard S/4HANA Cloud equivalent or flag as a gap.
  • Run SAP Readiness Check (verify availability for your source release) to identify custom objects that will not survive in the cloud extensibility model.
  • Validate whether your approval hierarchies rely on organizational hierarchy (O/C/P objects in HCM) or purely FI cost center structures — this matters significantly because S/4HANA Cloud uses SAP Business Partner and may have a different org model dependency.
  • Confirm your source release. Custom ABAP workflows built on SAP Business Workflow (transaction SWI1/SWDD) are not portable to S/4HANA Cloud; BTP Workflow Management or in-app Manage Workflows (Fiori app) are the target instruments.
  • Identify external system integrations (e.g., vendor risk platforms, treasury systems) that currently receive workflow events via RFC or ALE/IDOC — these need re-architected as REST/OData or SAP Integration Suite patterns in cloud.

Migration Sequence

  1. Freeze and baseline the current on-premise workflow in SWDD. Export decision logic as functional specs — do not assume you can lift ABAP code.
  2. Map standard coverage: S/4HANA Cloud’s SAP Fiori app “Manage Purchase Orders” combined with Flexible Workflow (Materials Management) supports multi-level approval with dollar thresholds, plant, and purchasing group. Verify in your version whether material group and vendor classification fields are available as routing conditions — gaps here are common.
  3. Model residual complexity on BTP: Routing logic that cannot be expressed in Flexible Workflow conditions (e.g., dynamic vendor risk scoring from an external API) should be externalized to SAP Build Process Automation (formerly BTP Workflow Management). This keeps the cloud core clean and upgrade-stable.
  4. Rebuild integration touchpoints using SAP Integration Suite (Cloud Integration). Replace RFC-based event triggers with OData Business Events or the SAP Event Mesh to push approval status to downstream systems. This is architecturally non-negotiable in cloud — no direct ABAP-to-external calls.
  5. Configure substitution and delegation rules natively in Fiori — do not recreate these in custom logic. The standard “Manage Substitution Rules” app covers most scenarios.
  6. Test upgrade resilience: In cloud, SAP delivers quarterly updates automatically. Any extension built in-app using Key User Extensibility (Custom Fields and Logic) survives upgrades; anything on BTP is your responsibility to maintain API compatibility.
  7. Parallel run: Operate both workflows simultaneously against a test purchasing document set before cutover. Validate approval audit trails match — auditors will require this.

Rollback Procedure

Cloud deployments have limited traditional rollback options — design for forward recovery:

  • Pre-cutover: Keep on-premise system in a read-only operational state for minimum 60 days post-go-live for in-flight POs.
  • Workflow state migration: POs with open approval tasks at cutover must be either force-approved/rejected on-premise or manually recreated in cloud. There is no automated state migration path — document the business rule for handling these.
  • BTP extension rollback: Version-control all SAP Build Process Automation artifacts in a Git repository. If a process revision causes routing failures, redeploy the prior version directly from the BTP cockpit without impacting the cloud core.
  • Integration rollback: Maintain Integration Suite iFlow versioning. A failed iFlow deployment can be reverted to the last active version without downtime — verify this behavior in your BTP subaccount configuration.

The core architectural principle: the sophistication your business requires is achievable, but it must be distributed — standard Flexible Workflow handles the core, BTP handles the complex logic, Integration Suite handles external connectivity. Consolidating all three into custom ABAP was the on-premise pattern; accept that the cloud equivalent is a federated architecture, and your upgrade exposure drops significantly as a result.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

The most significant difference is the extension model. On-premise gives you full ABAP workflow customization, while cloud forces you to work within the standard Fiori My Inbox framework or use SAP Build Process Automation for complex scenarios. This isn’t necessarily limiting - we found that 80% of our ‘custom’ requirements could be met with standard configuration of approval steps and conditions. The key is accepting that you won’t replicate exact on-premise logic, but rather redesign for cloud-native patterns.

4

Integration patterns are fundamentally different. On-premise workflows typically use RFC or IDoc for external system integration. Cloud workflows must use APIs - either OData services or REST APIs through SAP Integration Suite. This actually creates better decoupling and makes the approval process more resilient to system changes. However, you need to plan for API rate limits and design asynchronous patterns for scenarios where you previously had synchronous RFC calls. We moved vendor risk rating checks to event-driven updates rather than real-time lookups during approval routing.

5

That’s helpful context. How have you handled multi-dimensional approval hierarchies in cloud? Our current setup routes based on combinations of purchase value, material group category, vendor classification, and requester’s organizational position. Can the standard cloud approval determine handle this complexity, or did you need Build Process Automation?

6

For multi-dimensional routing, standard cloud configuration supports value-based and organizational approvals out of box. But complex combinations typically require Build Process Automation. The advantage is that BPA workflows are upgrade-safe and can be modified without code. We implemented a decision table approach where approval rules are maintained in a configuration table, and the BPA workflow evaluates these rules. This gave business users control over approval logic without developer involvement. The trade-off is increased complexity in the workflow design phase, but much easier ongoing maintenance.

7

The upgrade implications are crucial to consider. On-premise custom workflows often break during major upgrades because they modify standard objects or use undocumented function modules. Cloud’s standardization means quarterly updates happen automatically without breaking your approval logic - IF you’ve designed within the supported extension model. We had to simplify some approval scenarios during cloud migration, but the payoff is zero regression testing for workflow functionality during updates. Document any deviations from standard carefully, as these become your technical debt.

8

Don’t underestimate the user experience differences. Fiori My Inbox provides a much better mobile approval experience than classic workflow inbox. We saw approval cycle times drop by 30% just from the improved UX. However, users familiar with complex on-premise workflow screens may initially resist the simplified cloud interface. The approval hierarchy becomes more transparent to end users in cloud, which can be both positive (better understanding of process) and negative (more questions about why certain approvers are involved). Plan for change management around the new approval visibility.

9

Let me synthesize the key design considerations across all these dimensions:

Standardization vs Customization Trade-offs:

Cloud deployment fundamentally shifts the balance toward standardization. The supported extension points are:

  • Standard approval determination based on value, organizational assignment, or material group
  • Custom business rules via BAdI implementations (limited in cloud)
  • SAP Build Process Automation for complex routing logic
  • Custom fields and validation rules through key user extensibility

The critical decision is whether your business requirements truly need custom logic or if they reflect historical process design. We conducted a value stream analysis and found that 60% of our ‘required’ custom approval steps existed only because of past system limitations, not business necessity. Challenging these assumptions enabled cloud-native design.

For scenarios requiring genuine complexity (like your multi-dimensional routing), Build Process Automation is the strategic path. It provides visual workflow design, decision tables for rule configuration, and integration with external systems via APIs. The learning curve is significant, but the result is maintainable, upgrade-safe automation.

Approval Hierarchy Design Patterns:

Cloud architecture favors flatter, more transparent hierarchies:

On-Premise Pattern: Deep hierarchies with sequential approvals, often 5-7 levels, with complex substitution rules and ad-hoc routing

Cloud Pattern: Parallel approval tracks with clear escalation paths, typically 2-4 levels, with automated routing based on configurable rules

Implementation approach:

  1. Map current approval scenarios to decision criteria (value thresholds, risk categories, organizational rules)
  2. Design approval matrix showing when each approver type is required
  3. Configure standard approval determination for simple scenarios
  4. Use BPA for complex scenarios requiring multiple criteria evaluation
  5. Implement role-based approval rather than person-based to improve flexibility

The organizational hierarchy in cloud (using Org Model from SuccessFactors or custom org structures) becomes the foundation. Changes to org structure automatically update approval routing without workflow modification.

Integration Patterns Evolution:

The shift from synchronous to asynchronous integration is critical:

On-Premise: Workflow calls RFC to external system → waits for response → routes based on result Cloud: Workflow triggers API call → continues processing → receives event when external system responds → updates approval routing

This requires rethinking integration architecture:

  • Use SAP Integration Suite as middleware for complex integrations
  • Implement event-driven patterns where workflow subscribes to external system events
  • Design for eventual consistency rather than real-time data synchronization
  • Cache frequently accessed reference data (like vendor risk ratings) rather than looking up per transaction

For your vendor risk rating scenario specifically: maintain risk ratings in S/4HANA master data, updated via scheduled API calls or event-driven integration, rather than real-time lookup during approval routing. This improves performance and reduces external system dependencies.

Upgrade Implications Strategy:

Cloud’s quarterly innovation cycles fundamentally change upgrade planning:

On-Premise Reality: Major upgrades every 3-5 years, extensive regression testing of custom workflows, frequent breaks in custom approval logic

Cloud Model: Automatic quarterly updates, standard workflows continue functioning, custom extensions in supported frameworks remain stable

Critical success factors:

  1. Design within SAP’s published extension guidelines - these are upgrade-guaranteed
  2. Avoid modifications to standard objects - use extension points instead
  3. Document business rules separately from technical implementation
  4. Implement automated testing for approval scenarios using SAP Cloud ALM
  5. Participate in SAP Early Adopter programs to preview upcoming changes

The payoff is dramatic: we’ve gone through 8 quarterly cloud updates with zero workflow-related incidents, compared to 40+ hours of regression testing per upgrade in on-premise.

Practical Migration Approach:

For your specific migration:

  1. Assessment Phase: Document current approval scenarios, categorize by complexity (simple value-based, organizational hierarchy, multi-criteria complex)

  2. Design Phase:

    • Simple scenarios → Standard cloud approval configuration
    • Moderate scenarios → BAdI implementation or enhanced approval determination
    • Complex scenarios → SAP Build Process Automation with decision tables

  3. Proof of Concept: Build 2-3 representative workflows in cloud environment, including your most complex scenario, to validate approach

  4. Iterative Implementation: Start with simple scenarios, gain user acceptance, then tackle complex workflows

  5. Change Management: Emphasize improved mobile experience, faster approvals, and better transparency rather than feature-for-feature comparison with on-premise

The goal isn’t replicating on-premise functionality exactly, but achieving the same business outcomes using cloud-native patterns that are more maintainable and upgrade-resilient.