Flexible workflow in S/4

Workflow solutions have been widely used in SAP systems for many years. They are most often implemented to handle processes related to document approval. In the area of purchasing, these are primarily the processes for approving purchase requisitions, purchase orders and invoices. In classic SAP ECC systems, decisions in workflow processes are made using the SBWP transaction in the SAP GUI.

Although these are proven solutions, technologically they are no longer compatible with today’s requirements. First, they do not offer mobile approval on mobile devices. Secondly, they are quite difficult to modify, e.g. changing the expense approval policy often requires the involvement of a consultant to make configuration changes as part of the so-called approval strategy. In addition, the workflow templates available in different areas of the SAP ECC system are not consistent with each other, which makes it hard to implement and maintain such solutions.

Mobile approval for SAP ECC systems is available via the independent SAP Fiori Front-End Server.

The traditional workflow is still available in SAP S/4HANA on-premise and private cloud versions. In the S/4HANA public cloud version, it is only possible to use the flexible workflow, while more advanced or non-standard workflow needs can be implemented on the Business Technology Platform (BTP) in the BTP Workflow Management component.

When designing the SAP S/4HANA system, its developers planned a completely new workflow functionality addressing document approval requirements, the so-called flexible workflow. The flexible workflow offers functionalities that were available in the past, such as conditional triggering of workflow processes (e.g., an order belongs to a specific company code and exceeds a certain amount), free user determination (e.g., purchases above half a million zlotys are approved by the CEO), multi-staging, etc. At the same time, it offers a completely new quality thanks to the modern and user-friendly SAP Fiori interface, which provides full out-of-the-box mobility.

Approval-related decisions are made in My Inbox, an application available as a tile on the SAP Fiori Launchpad page. Additionally, the flexible workflow is not only about configuration but rather about settings treated as master data. In the case of changes to the expense approval policy, the approval paths are edited by the key user. It is also worth mentioning that the flexible workflow is a generic feature of SAP S/4HANA, i.e. it is available in all areas of the system. Processes in other modules apart from the purchasing module are described in the system documentation available at help.sap.com (https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/).

The flexible workflow is available in every version of SAP S/4HANA, whether on-premise, private cloud or public cloud.

In this article, we will discuss the following components of flexible workflow in SAP S/4HANA systems:

• Base configuration;
• Application #1 Manage workflows – flexible workflow setup using the example of a purchase order with cost center (CC) account assignment;
• Application #2 Manage Teams and Responsibilities – setting up teams whose members are assigned different responsibilities;
• Application #3 My Inbox – an inbox where decisions are made;
• Notifications;
• Other information.

Base configuration

To use flexible workflow in SAP S/4HANA, it is necessary to activate the workflow environment in almost the same way as in SAP ECC (SWU3 transaction). There are minor differences, e.g. in SAP S/4HANA, the technical user of the workflow is SAP_WFRT, and in SAP ECC, it is WF-BATCH. In addition, there is no need to manually schedule batch tasks related to the workflow engine since in SAP S/4HANA they are automatically scheduled based on the definition of standard tasks (SJOBREPO transaction).

The SAP S/4HANA on-premise and private cloud system can be used in the same way as SAP ECC, i.e. through the SAP GUI client application. However, the flexible workflow is only available through the browser and the new SAP Fiori user interface. Therefore, all services related to the Fiori front-end must be active and the appropriate user roles containing catalogs and SAP Fiori groups or spaces must be developed. It is also necessary to make some basic module settings (e.g., the flexible workflow framework can be activated for selected purchase order types).

In some classic applications, the flexible workflow is visible in read-only mode, e.g. the approval path can be seen in ME22N/ME23N transactions on the Flexible Workflow tab. However, the traditional workflow implemented based on the approval strategy is not visible in SAP Fiori (there is no Approval Strategy tab).

Application #1 Manage workflows

The Manage workflow application is designed for the key user (not the consultant!) who manages the workflow processes in a given system. In the application, we first select the area for which we want to set up a workflow (in our example, it is the Workflow for purchase orders). After selecting the area, a list of active and projected workflow processes appears (inactive processes have a temporary document status).

It is worth noting that the workflow process settings are treated as master data, not as configuration. The key user edits these settings directly in the production system. The set active workflow processes are checked by the system according to the order from top to bottom; the order, of course, can be freely set. The point is that a new purchase order document may meet the conditions for starting several processes, but the first one will be used.

An active workflow process cannot be edited, as workflow process instances may have been launched. If you want to modify the settings of a process, we need to create a copy of it, modify it as needed, and then deactivate the previous process and activate the new one.

A new workflow process is set up at two levels. At the first one, a description of the process, its validity period and the so-called initial conditions are developed. Examples of initial conditions include the assignment of a purchase order to a specific company code or a purchasing department, the net purchase order amount in the document currency (greater than, less than, or equal to), the type of purchase order document used, or the use of a particular account assignment in the purchase order, such as a cost center or a project. The individual conditions are treated together, but it is also possible to add alternative conditions. Once the starting conditions are developed, approval steps are created.

Editing the settings of a step is, so to speak, the second level of settings (different for each step). For each step, the name, the optionality of the step, the excluded users (e.g., the creator of a purchase order can be automatically excluded from a particular approval process for their purchase order if they are among the approvers at some stage at the same time) and, of course, the recipients are set. It is possible to assign recipients through a role or directly through a user name. However, the term “role" in the context of flexible workflow is something different from the traditionally understood permission role edited in a PFCG transaction. There are five types of roles within the flexible workflow:

• Related to the organizational structure, e.g. a supervisor, a supervisor’s supervisor, supervisor of the person at the previous stage;
• Related to the account assignment object, e.g., a cost center owner, a person responsible for a project;
• Related to functions within teams, e.g., a team member of operational buyers or strategic buyers/key account of strategic managers;
• Workflow administrator;
• Custom determination of a processor.

Direct assignment of the user requires them to be linked through infotype 0105 with an employee record and to have a business partner (BP) record with the Employee role. In S/4HANA on-premise and private cloud versions, these links are created traditionally in the SAP GUI, while in the S/4HANA public cloud, a dedicated SAP Fiori application is created for this purpose.

An important setting in the context of recipients is also the indication whether a decision should be made by one of the individuals specified at a given stage, or by all of them.

Another very important element is the ability to develop step activation conditions. Examples of conditions include the use of a given account assignment: cost center/project, the use of a given material group, document type, purchasing group, purchasing department or net purchase order value in document currency (greater than, less than or equal to).

After setting up the recipients, step activation conditions, it is still possible to set up deadlines and actions in case of a negative decision in a step. For example, if a deadline is missed, it is possible to simply mark the task as overdue or send an e-mail notification. In the case of a negative decision, this may be marking the purchase order as rejected or sending it back to its creator for correction.

The screenshot demonstrates the setup of a sample approval path in the company code 2610, for purchase orders over PLN 1,000 with a cost center account assignment. There are three approval steps in the path. The first one is the approval of the owner of the most heavily burdened cost center (the use of multiple cost centers in one purchase order can be limited), the second step is the approval of one of the purchasing team members (only when the purchase order exceeds PLN 10,000), and the third step is the approval of the area manager (only when the purchase order exceeds PLN 50,000).

Fiori applications for flexible workflow

Application #2 Manage Teams and Responsibilities

The Manage Teams and Responsibilities application is a brand new concept available in the S/4HANA system. One of the uses of this application is the flexible workflow area. In the previous section, it was mentioned that the recipients of tasks can be people who perform certain functions (roles) within teams. In the application, a key user can create and manage teams that are responsible for a specific area. A team has a responsible person, members and a so-called definition of responsibility (e.g., a team can be responsible for the 2610 purchasing department).

Special attention should be paid to the fact that functions are assigned to each team member. The types of teams and functions can be freely modeled. In addition, teams can be linked to each other through superior/subordinate relationships, which enables the hierarchy of teams to be reflected.

In the example in the screenshot, the Operational Management function was used and assigned to two people. The Operational Management function was previously selected as the role for the recipients in the second step of the sample approval path.

Application #3 My Inbox

The My Inbox application is a place where workflow decisions are made in the SAP Fiori environment.
Its counterpart on the SAP GUI side is the SBWP (Business Workplace) transaction. Tasks generated by the flexible workflow are visible in SBWP, but they cannot be executed from there. The My Inbox application should be used only. On the left side, the application displays a list of tasks (workflow work items) to be executed along with key information, such as the number of the document to which the task relates. On the right side, there are details of the selected task/document. The screen area is large, especially on a desktop, so it is possible to display quite a lot of information. Decisions are made via buttons at the bottom right of the screen.

First of all, a purchase order can be either approved or rejected. In addition, it is possible to view the log, take ownership of the task (when it is sent to multiple recipients at once) or forward it to another person. The new inbox also offers the option to designate a substitute and display information about whose substitute one is currently. The functionalities described are analogous to those known from the SBWP transaction. In the author’s opinion, one of the most interesting new features is the ability to collectively make decisions (e.g., a user has 12 purchase orders to approve in the inbox and wants to approve them all at once).

In the case of ECC systems, dedicated ABAP cockpits had to be developed for such a requirement. In My Inbox, this functionality is available out-of-the-box. There is also the My Outbox app that shows a history of decisions made in the past. The screenshots present the purchase order acceptance task on a desktop screen and the same task in the mobile device emulation mode.

Notifications

Notifications are particularly important in any workflow environment. These are messages to people involved in the workflow process delivered to them through a communication channel other than the workflow itself, mainly by e-mail. Notifications are intended to inform about a decision made in the process or to remind that some workflow task should be performed. In the flexible workflow, there are two types of notifications:

• E-mail notifications;
• Push notification.

There are four types of email notifications (in the purchase order approval scenario):

• Notification of a pending task;
• Notification of a positive decision (acceptance);
• Notification of a negative decision (rejection);
• Notification of exceeding the deadline for completing a task.

Email notifications are activated by copying the appropriate template provided on a standard basis by the manufacturer (different templates are available for different scenarios, of course). The activated template can be edited and customized. It is worth noting that the template is prepared using HTML5/CSS technology, so it is possible to design templates tailored to the company’s visual identity. Available variables can also be used in templates, e.g. to display the order number, net amount, document creation date, etc. Template preparation, like the development of workflow path settings, can be done directly in the production system.

New elements, often referred to as alerts, are push notifications. They are automatically published on the SAP Fiori Launchpad page (bell icon). From this notification, you can go directly to My Inbox and make the required decisions.

Other information

It is impossible to describe all the details of the flexible workflow, nevertheless the following aspects seem important from the perspective of a person planning to implement this solution:

• Applications can be extended with dedicated fields;
• Applications can be extended with dedicated logic, in particular:
  • It is possible to implement custom person determination algorithms for decision tasks;
  • It is possible to implement custom activation criteria and algorithms for their evaluation;
  • It is possible to implement custom algorithms that restart the approval process;
• Workflow settings can be translated into various languages;
• Workflow settings – although they are like master data by default – can be transferred from development to quality and production systems (as they traditionally have been);

Applications for the workflow administrator are also available.

For companies with processes implemented on the basis of the so-called approval strategy in the MM module, it is important to make sure that the classic workflow is turned off before starting the flexible one. This is because the solutions are mutually exclusive and only one should be used.

Flexible workflow in the purchasing area – other options

This article describes the flexible workflow using the purchase order approval as an example. Other available documents in this area for which approval paths can be activated include:

• Requests for Quotations (RFQs);
• Quotations;
• Scheduling agreements (a form of a framework purchase order);
• Contracts;
• Purchase requisitions;
• Service acceptance sheets;
• Invoices;
• Sourcing projects;
• Supplier lists for sourcing;

The solution documentation includes also such terms as central purchase orders, central purchase requisitions, etc. This applies to scenarios in which the S/4HANA system is set up as a central purchasing hub (as SAP SRM has been until now).