The Future of SAP Workflow Management

Organizations can build, automate, and manage workflows in a cloud environment with the help of SAP Workflow Management, a cloud-native service offered by SAP.

It offers a low-code/no-code approach, allowing both business users and developers to create, alter, and automate workflows without having substantial coding experience.

While SAP Workflow Management is a powerful tool for automating and managing workflows in a cloud environment, like any technology, it has some limitations as well such as handling complex workflows, complex integrations, performance, handling high data volumes, offline support, automation, and so on. In addition, it was found that the learning curve is high in practical cases. SAP has announced the retirement of SAP Workflow Management and has introduced a more modern, comprehensive, and “citizen friendly” tool called SAP Build Process Automation. The key differences between SAP Workflow Management and SAP Build Process Automation are summarized in this table

Because SAP Workflow Management capability has been replaced with SAP Build Process Automation, the direction forward for SAP Workflow Management customers is to build new workflows in SAP Build Process Automation. Existing workflows built in SAP Business Application Studio can be consumed in SAP Build Process Automation. SAP has provided some migration options. However, there are some constraints in these migration options. While the SAP Workflow Management solution was available in SAP’s own data centers (for Neo) and various hyperscalers (for Cloud Foundry), SAP Build Process Automation is available only in limited Cloud Foundry data centers.

Let’s take a quick look at the process of moving to SAP Build Process Automation, as follows:

• Workflows: Though the ideal solution would have been to get the existing workflows developed using SAP Workflow Management converted easily, unfortunately it isn’t possible. Due to a different internal architecture, existing workflow models won’t be converted automatically into the process builder in SAP Build Process Automation; rather, the new workflows should be built in SAP Build Process Automation. Workflows built in SAP Business Application Studio, however, can be modified in SAP Business Application Studio and deployed to SAP Build Process Automation.
• Business rules: Business rules projects from an SAP Workflow Management subaccount have to be imported into an SAP Build Process Automation subaccount and need to be redeployed as rule services in an SAP Build Process Automation subaccount. The user and role assignments within the SAP Build Process Automation subaccount will also be needed for further modification, deployment, and management of these rules. The business rules directly deployed to SAP S/4HANA need to be recreated as projects in the SAP Build Process Automation subaccount before they can be used.
• Process visibility scenarios: The visibility scenarios from the SAP Workflow Management service need to be imported into a business process project and then be redeployed. Once imported successfully, they can be adjusted just like the visibility scenarios created as part of the business process project in SAP Build Process Automation.

Editor’s note: This post has been adapted from a section of the book Workflow for SAP S/4HANA by Sabyasachi Dutta, Nilay Ghosh, Kousik Goon, Sandip Jana, Arindam Mukherjee, Srinivas Rao, Yogeendar Rao, Yogesh Sane, Naveen Veshala, and Kiran Viswanathan.