Skip to Content
Technical Articles

How to develop your first Workflow Scenario in SAP S/4HANA Release 1909

The short answer … do not use the SAP Business Workflow Builder.

Instead, if you want to model a workflow,

  • for complex processes, particularly those spanning different systems, use the Workflow service in the SAP Cloud Platform (described in detail in the SAP Learning Journey)
  • for simple processes, particularly approvals, build a workflow scenario instead (read on)

You can refer back to the previous positioning blog to understand why.

This blog gives you a step-by-step account of how to create your own workflow scenario in S/4HANA On-Premise installations. It cannot be done in SAP S/4HANA Cloud; where you’ll use the integrated workflow scenarios delivered as part of the software, or the SAP Cloud Platform Workflow service for new processes.

Why create a Workflow Scenario?

Previous blogs have described in more detail what a workflow scenario is in the S/4HANA sense. Think of those childrens’ toy kits containing Lego® blocks which the children can snap together to build, say, a spaceship or, a hospital. They’ll be packaged in different boxes but use the same framework. The children can follow the instructions and build the exact replica of what is shown on the box, or they can create their own variations. And the individual building blocks are made from the same casts so a child building the spaceship will be familiar with the different connection mechanisms and use this experience when building the hospital or any other construction.

So it is with the workflow scenarios. The S/4HANA applications have assembled their own kits, for example one from procurement geared to handle purchase requisition items, and one from sales geared to handle sales quotations, but the customer can plug the blocks together according to their own preference to the relevant approval process exactly as they desire from these “scenario” kits.

When you build a workflow scenario instead of the exact workflow you enable the business process expert in your company to take full control of the approval processes, redesigning them and publishing the changes as often as they desire, without the burden of learning workflow design and coding themselves. There are other side-benefits since this has been the focus of development of SAP’s ABAP-based workflow since the conception of SAP S/4HANA and offers many advantages over the classic workflow, such as the embedded visualization of the process and ability to ad hoc change the process on the fly. Aggregating these new features explains why such workflows resulting from scenarios are referred to as flexible workflows.

I’ll leave the Lego® analogy now, but not without first blatantly plugging the First Lego® League for those of you with children. the most thrilling introduction to technology that you you can give to any child anywhere in the world!

For the purpose of this blog, I will recreate a workflow scenario that has already has delivered as part of SAP S/4HANA so that you can deep-dive and examine the detail yourself if you so choose. The workflow scenario covers approvals for Sales Quotations, and has the ID WS02000447.

♥ Tip – Before you launch into this, you may want to remind yourself of what the result will look like to the process participants and process expert modeling the workflow by watching the short videos in this overview blog.

Phase A: The Workflow Scenario Stub

Step 1 Verify the development environment

Because this is On Premise your administration will have to have configured the the workflow environment themselves. You should verify that this has been completed using transaction SWU3 before you continue. And make sure you verify the workflow definition environment, too, because a workflow scenario is a development object. At the very least the prefix numbers and number ranges shown at the bottom of <fig 1> must have been maintained, as well as the run-time environment which you’ll rely on later.

 

Fig 1. Check that the definition environment has been maintained in transaction SWU3

 

Step 2 Create the scenario stub

Invoke the workflow scenario editor SWDD_SCENARIO to start creating the scenario. This may look similar to workflow builder, but it is not the same. You cannot edit workflows using this editor, and neither can you edit workflow scenarios with the workflow builder.

♥ Tip – transaction SWDD_SCENARIO_DISP can be used to display workflow scenarios.

Ignore the graphic frame and select new to create a new scenario. The graphic frame is a left-over, serves no purpose, and is likely to be removed at a later date after more urgent developments have been completed. Whenever you see the graphic frame, just click on the “S” highlighted in <fig 2> and that will take you to the scenario detail.

Fig 2. Create the stub of the scenario

Now you can give your scenario a unique abbreviation and a description to identify it.

  1. Abbreviation [scnSalesQuot}
  2. Description [SCN Sales Quotation]

Phase B – Specifying the scenario context

Now comes the all important step, configuring the scenario context by declaring a leading object. Whereas classic business workflows may have several leading objects, a workflow scenario only has one. As described above, this scenario will enable workflows to be created in the Fiori Manage Workflows app for sales quotations, so we choose the ABAP class encapsulation of sales quotations as the context. You could use your own BOR or ABAP Class here to represent your own context, or choose an already existing BOR object or ABAP Class as I have done here.

Step 3, Create the leading scenario context.

Fig 3. Specifying the scenario context

Double-click on the new scenario context branch to define the scenario context. Make sure you specify its property such that it is import and mandatory. After all, you cannot expect users to approve objects that don’t already exist!

So when creating this scenario context element you specify:

  1. Element ID   [scnSalesQuotation]
  2. Element name [SCN Sales Quotation]
  3. Short description [Sales Quotation for SCN blog]
  4. Object type [CL_SD_SALESQUOTATION_WORKFLOW]  (ABAP Class)
  5. Properties: Input, Mandatory.

Step 4 – Assign this context as the leading scenario context

After you have entered the scenario data you will see your context appear in the scenario context list and you can now declare it as the leading object.

Fig 4. Scenario context specified

You can also create other container elements,  just as you can do for classic workflow, but this leading scenario context element is mandatory.

Phase C – Specifying the activities in your scenarios

This is the fun bit. Here you can go to town adding possible activities to your workflow scenario. There is no need to restrict yourself to simply an “approve” task, you can specify different approval tasks such as “business approval” or “customer validation”.The activities are building blocks that will be strung together much later by the business expert when modeling the workflow process in the Fiori Manage Workflows app.

Bear in mind that the description of the activity is what is presented to the business process expert configuring the workflow so type a description that is self-explanatory.

Step 5. Create a new activity

Navigate to the activities tab and select new to create the new activities in the scenario.

Fig 5. Creating a new activity

♥ Tip: When a task (work item) is generated from a workflow based on your scenario, the text of the work item displayed in the Fiori My Inbox app is the scenario’s activity title and not the workflow step’s name.  The same is true of the log. For this reason it is worth creating different activities for the different types of approval that you can envisage or the approver will find it difficult determining what type of approval she is performing.

Fig 5b. The new activity

You have a choice between a user decision or an activity. We will select user decision in this example because we are only interested in an outcome to the decision.

Note: If you choose an activity instead of a user decision, there will be no outcome and the method wrapped in the task’s BOR object/ABAP class will be invoked if you select a background task. However, consider carefully whether you want to burden the process expert configuring the workflow with adding this task in the relevant portion of the workflow, or whether you can embed this directly in the result-callback method described at the end of the blog.

If the task is a dialog task, it will be rendered by the HTML GUI from My Inbox, unless you have configured the execution differently in SWFVISU.

User decisions on the other hand determine the buttons rendered in My Inbox, but the code defined in the task is not executed when invoked from My Inbox. If code needs to be executed, such as to validate the decision, then this should be coded into the exits described later.

Give the activity a name and leave the “activity results processing” box unchecked so that it will later appear as a step in the Fiori Manage Workflow app. This box is only used when you have an activity that may NOT be selected as a step when creating a workflow, but is only used for exception handling.

Step 6. Specify the possible decision outcomes

The outcome is important. These are displayed as buttons in My Inbox  But above all, the character of the outcomes determine the path followed by the workflows defined later in the Fiori Manage Workflow app,

Before moving to the next step it is worth taking a second look at the significance of the outcome nature summarized in the table below.

Nature Process continues unabated Result is treated as positive Process-Exception Coloring of the My Inbox button
Positive Yes Yes No Green (for first positive outcome only when several are defined)
Neutral Yes Yes No Grey
Negative No No Yes Red (for first negative outcome only if several are defined)

But beware, the color is the logical color, and may vary according to a user’s preferences. And the call-back logic could be coded in such a way as to have a different effect on the outcome, for example by coding the …STEP-AFTER_COMPLETION method described later.

Fig 6. The activity outcome

As with classical workflow, the title of the decision may include parameters and is displayed in the list and detail views in  My Inbox. It is translatable.

♥ Tip It is good process-hygiene to switch the task used in this activity to use a copy of TS00008267 (the standard decision task) instead of referencing the original. This helps with the administration and avoids misleading reporting. You can copy and switch the task later after the initial testing. The task is automatically classified as a general task during import into the production system, as with all other tasks embedded in workflow scenarios.

Step 7 – Save the scenario

You have defined a significant portion of the scenario so now is a good time to save the scenario. This will generate the scenario ID. Since this is a custom scenario, it will follow the pattern WS9nnnnnnn, where the number n is depends on the number range configured in step 1. Don’t be misled by the fact that workflows also have the prefix WS. You have not defined a workflow, but a workflow scenario and it cannot be maintained in the transaction SWDD.

 

Fig 7. The scenario has been saved

You may have spotted that I have added 2 activities, and this is reflected in the title of the activities tab.

Phase D – Start conditions

Under the conditions tab you can specify the conditions available when modeling a workflow in the Fiori Manage Workflow app determining which workflow is to be started, and which of the steps in the workflow are to be executed.

All conditions can be used in the Fiori Manage Workflow app to determine whether the step in the workflow is executed, but only if you select the Start Condition check-box can this condition be used to configure whether or not that workflow will be started.

Once you have specified the name and description of the condition, you can define the Boolean logic in the next screen using that same editor as is used to specify conditions in classic workflows.

Step 8 – Add the condition

  • Unique name [SalesOrg100]
  • Short text [Sales Organization 100]
  • Description [Sales Organization 100]

Fig 8. The new condition

Step 9 – Configure the condition

Fig 9. The Boolean rule behind the condition

Adding a parameterized condition.

Obviously it makes little sense adding a separate condition for every sales organization. A more efficient way of achieving this is by using parameters, which the colleague maintaining the workflow specifies while creating the workflow in the Fiori Manage Workflow app.

Fig 9b. A parameter in the condition

If you are impatient and want to test your scenario now, then you can do so without completing the following steps. Just skip to step 13 – activation.

Phase E – Additional characteristics

Step 10 – Agent Rules

You can add your own rules here, such as the owner of a Sales Office, but you see that 3 standard workflow rules (initiator,  superior of the workflow initiator, and workflow administrator) have already been included and are sufficient for initial testing..

Step 11 – Value Help

You can make it much more comfortable for the process expert by enabling her to use pick-lists to populate the workflow conditions. For example with the  sales organization parameter, she would be able to select from a list as opposed to remembering which is which.  Specify the Odata Service to be used to populate the pick-list. If there is no existing service offered by the application then you will need to create a CDS view to enable this.

The <people-picker> Service is used to specify a pick-list for a single user as recipient for a task. As with classic workflow this is not to be recommended, If you do want individual task ownership to be offered, then you can create your own service that restricts the users to satisfy GDPR concerns.

Figure 11. The value-help configuration

Step 12 – Reference Times

Reference times are used to calculate the offset for deadline monitoring. Out of the box you already have the time the workflow process is triggered, as well as the time the step is delivered as reference points that can be used to specify deadlines in the Fiori Manage Workflow app. But you could add your own based on an expression from the workflow scenario container, such as the sales quotation validity date. Attributes of the scenario context or calculations based on the attributes are valid references.

Phase F – Activating and Testing the Scenario

Step 13 – Check

You can add more detail later, but your scenario is already sufficiently configured to activate and get a feel for what the colleague modeling the processes will see. As I wrote at the beginning. ignore the graphic frame because it has no meaning. You can check the scenario and make use of the linked messages to take you the erroneous section should there be any)

Step 14 – Activate

Pressing the activate button will also perform a test, and if all is well, generate internal artifacts of the scenario (step 14) so that it can be used.

Fig 13. Activation

To test the scenario you need to logon to the launchpad with a role that has sufficient authorization to invoke the Fiori Manage Workflow app by configuring it as a tile or by invoking it directly through the semantic action URL:

E.g.      mylaunchpadurl#Workflow-showList&/Scenarios/WS9nnnnnnn

(where WS9nnnnnnn is your scenario ID)

 

Phase G – Essential! Dealing with the Results

You’ll have seen in previous blogs that the workflow simply returns the result of the decision to the invoking application, but the application must perform the relevant action, such as in this case releasing the sales quotation. This is achieved using a call-back mechanism.

Fig 14. The runtime data class

If you look at the control tab of a scenario delivered by SAP, you’ll see that an ABAP class has been implemented that supports the IF_SWF_FLEX_IFS_RUN_APPL interface and is assigned to deal with the workflow runtime data.

Fig 14. The runtime data class result-processing method

Step 14 – RESULT_CALLBACK

Many of the methods simply inherit the basic workflow method, but the RESULT_CALLBACK method must be coded out.  This method is invoked when the workflow terminates normally, such as after the last approval has taken place. This is the place to code the release/status-change of the underlying business object. The method is not invoked when the workflow is canceled (there are other methods at your disposal for handling this, if extra handling is needed) so in simple scenarios it is  sufficient to perform the final processing of the business object (e.g. status change) here, but to be on the safe side it is worth coding a check to make sure that the last decision made did indeed have a positive outcome.

Have a look at SAP workflow scenarios to get a better feel for what can be coded here, as well as how the other (optional) methods are used.

Step 15 – Process Exceptions

You will have read in a previous blog that activities can be offered to deal with process exceptions, such as by editing the  business document, or providing additional information. These mitigations are simply activities provided along with the other activities in the workflow scenario with one important difference. When the process expert configures their workflow and selects the mitigation activity from the list, they cannot specify who should perform the task – it is an implicit part of the activity. So to specify that an activity is a mitigation activity you must assign the activity a default role, almost certainly the workflow initiator.

Fig 15. The default role for process exception activities

Only activities that have a default role specified will be offered as exception mitigation in the Fiori Manage Workflow app. To avoid having the mitigation appearing as a normal possible step in the Manage Workflow app check the activity results processing checkbox as described earlier.

Documentation

Do make sure you provide documentation for your end-users, in particular for the process expert configuring the workflows. Use whatever tool is most widely used in your company, but here is a good example from SAP to give you an idea of what your documentation could include.

Skills needed

So who has the skills to create these workflow scenarios at a customer site?

I don’t see the need to be a workflow guru, but basic SAP Business Workflow Experience helps, particularly when it comes to understanding process security, role-management and workflow eventing. Best of all is obviously someone who has built a workflow scenario before who has experience of nudging the business experts to string together their own workflows based on the workflow scenario that you have built. This is an important step, giving the customer the freedom to reconfigure their workflows at a moments notice whenever the need arises.

I also recommend that it should be someone with ABAP skills.

Not covered in this blog

This blog covers the basic structure of the workflow scenario and how to model it. In the interests of time I have left out many other aspects that could be of use to you, as they have been of use to to many S/4HANA applications.

Not covered in this blog:

  • Email notifications for the process outcome – the Output Management Email Templates can be configured and assigned to the process outcome in the control tab.
  • Pre-delivered content – to specify a default workflow that is active before the process expert configures her own.
  • Other types of workflow scenario in addition to the standard type – for different process needs.
  • Run-time events – for example to cancel the workflow and then trigger a different workflow when the business object is changed after the approval has started.
  • Team and Responsibility management (which at the time of writing cannot be used in a customer-built scenario)

However, as was the case with SAP Business Workflow many years back, I’m confident that the SAP community will discover these and publish useful blogs and forum entries to spread the detailed knowledge elsewhere. Get to it. Get your company’s work flowing.

Blogs: Previous | The trail has ended.

9 Comments
You must be Logged on to comment or reply to a post.
  • Alan – it is like a chapter in the SAP Workflow book.  Very well done.  Thank you for all of your support to the SAP Community and ASUG.  Good luck

  • Hi Alan,

    Thank you for such a detailed blog on flexible workflows. I have worked on S/4HANA Cloud workflows’ configuration and i could clearly visualize how all those features are developed in background. Many Thanks!

    Agent Determination – I understand that it will be done through ‘Team and Responsibility Management’ application, but I am not able to imagine how WF scenario and agent determination will string together.

    Also, since agent determination capability ( ‘Team and Responsibility Management’ application ) is not yet available for custom-built scenarios, is it advisable to develop flexible workflows for a S/4HANA implementation? ( I really don’t want to get into a situation where some capability is not yet available in flexible workflows, but easily available in SWDD ).

    Above snapshot is from blog, It should be fig 2 here.

    Regards

    GK

    • I’m no longer working for SAP so rarely see these comments (hence won’t reply).

      I haven’t understood why T&R (a native S/4HANA , not workflow, development) isn’t available for custom workflow scenarios (overlooked?, bug?, deliberate?) so I’d recommend you to follow up internally.

  • Hi Alan.

    Really nice informative well-described article. As i believe, we can only send workitems in parallel manner where all should approve or any one should approve. One query we have is that is it possible to send the workitems to n-approvers in sequential flow i.e. one after another.

    Regards

    Mohit Kumar