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.

2

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?

3

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.

4

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.

5

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.

6

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.