Skip to Content

SAP Workflow Strategy - A high level design


This document is a preceding document to Workflow Development Standards posted here on SCN.

The purpose of this document is to define a generic Workflow Strategy for a project. This answers some of the basic questions and sets the ground rules for all workflows to be developed in a project. Specific Development Standards are covered in a separate document called Workflow Development Standards.

Please note that this document is a generic document and has to be enhanced further depending on your project requirements. The Workflow Strategy of your project should not be limited just to these points; it can be further expanded based on individual project requirements.

This document is a collection from various sources, put together in a logical order.

1.1.1.    When to use/not use workflow

There is one document which clearly explains the usage of SAP workflows, some basic requisites and answers the fundamental question whether one needs workflows or not:

Guide to SAP Business Workflow and Its Role within Your SAP Infrastructure

1.1.2.    What technologies (and devices) do you support for inboxes, user interfaces, what inboxes are supported and which features of the inboxes are supported

This is an important question to be answered before going down the workflow lane. The user interface would determine whether vanilla workflows would work directly with the front end technology / device used or would we need something in addition.

For example, if your customer is using SAP GUI on PC/Laptops/Notebooks, you would not need additional software to access SAP Workflows. SAP Business Workplace is integrated within the SAP system and needs no additional support in this case.

If the SAP Enterprise Portal is used, we may need additional effort in setting up the UWL to access Workitems from the connected systems. However, if your front end is a separate s/w, you may need to build Workflow Access APIs to list the work items, to manage their processing options, including execution and object support. Furthermore, if the users will use Mobile Devices to access Workflow Items, you would need to consider the Mobile OS and how the workflow would be supported on that.

Some examples of different UI and Devices are given below:

Duet for SAP Workflows

Sybase Mobile Workflows for SAP Business Suite

SAP Fiori Approval Apps - A Technical Introduction

SAP NetWeaver Portal Mobile Edition – Overview

Here are two links for a comparative study of which Inboxes to use depending on your need:

Which Workflow Inbox When?

Workflow Inbox Feature Comparison Matrix

The above are examples to show how the UI and Devices used by your customer can impact the overall implementation and development of your workflows. Please consider and include these aspects in your Workflow Strategy.

1.1.3.    Who is responsible for workflow admin/support & how is workflow support shared between business and technical expert

Workflow administration consists of the people, processes and behaviours necessary to ensure:

  • The overall health of the workflow system – i.e. that workflows and supporting batch jobs operate with optimal efficiency
  • Responsible for the scheduling and execution of standard workflow batch jobs
  • Responsibility for inbox administration and configuration
  • Responsibility for Email Notification of New Work configuration and scheduling
  • Responsible for the configuration of the workflow environment (i.e. non-process-specific settings for workflow such as the workflow RFC destination and workflow Event Queue)
  • Proactive correction of misdirected and orphaned workflows
  • Proactive resolution of workflows in error
  • Reactive response to reported workflow issues where Help Desk has been unable to resolve issues
  • Responsibility for producing and monitoring agreed process metrics, such as SLAs

All workflow administrators must have SAP User ids.  Workflow administration activities may be split between:

  • A technical administrator
  • Business administrators

It is usual in such a split that the technical administrator is responsible for overall health and troubleshooting of workflows in error, while business administrators are responsible for redirecting misdirected workflows in their process area.  Ideally the business administrator should be the person responsible for maintaining the relationships used to find the workflow agents, so that they are also incented to prevent future misdirections by correcting the underlying relationships.  Business administrators may be a business champion or process expert.

Technical workflow administrator is expected to be a full time role.

Business workflow administrator is expected to be a small part of a larger business champion/process expert role.

Helpful link: Workflow Runtime Administration

1.1.4.    Will you identify recipients as users, positions or roles

The decision of identifying the positions or users as work item recipients are important, especially related to Concurrent Employment where one user may hold two positions.

Also, it is good to have Positions as recipients so as to have automatic integration with Organizational Structure (if implemented). Any changes to the organizational structure are automatically reflected in the workflow.

Identifying Roles as recipients will most commonly include sending work items to multiple agents. Example, a Shared Services Role can be a valid recipient of a work item, where a team of professionals can pick up your request.

It is important to define the Agent Determination strategy in this section. Establish a standardized approach to workflow agent designs and implementation that promotes efficiency reduces workload and maintenance issues. Also provide basic settings requisites for each rule type.

Define Guidelines, for example:

  • The underlying workflow agent determination rules should not be visible to common users
  • Workflow agent rules used to identify escalation agents should not identify escalators above a “Director” level. This is to ensure senior officers are not flooded with inactioned workflow requests auto-escalated from lower level subordinates. Items that should be referred to a “Director” or above would be referred utilising the current processes established
  • Workflow should not allow a manual or automatic assignment or reassignment of a task back to the requestor as a recipient – this to ensure separation of duties

1.1.5.    What is the approach for forwarding and substitution

Agent Authorizations (Possible Agents):

Unless critical sensitivities are identifed, all tasks will be marked as “General Task” ensuring that the assignment of work is based on recipient determination only

Where critical sensititives are identified, tasks will be marked as “General Forwarding Not Allowed” and assigned to specific security roles. This should be an exception to minimize impact on security roles.


Substitution affects all work items assigned to the original user in the case of user to user substitution rules, all work items assigned to the original position in the case of position based substitution rules.

Position based substitutions should be created centrally on request.

Active substitution will be supported. 

Passive substitution may be supported e.g. to enable certain managers to access the inboxes of their subordinates where close monitoring of inbox response is required. This may require enhancement or replacement of the standard “Manage Substitution” function in the UWL as this supports user to user substitution only currently.

More information can be found in Note 74000 - Q&A: Substitution in Business Workflow

1.1.6.    What is the expectation around tailoring and personalization

Define the expected layouts expected by users. It is important to categorize the views by roles.

For example, if UWL is used, you may need to define the strategy around what Objects are visible to the users and what actions can be performed. Example, upon rejection, a mandatory popup is required to enter a rejection reason, Renaming of buttons, addition of common dynamic values across work items and so on.

1.1.7.    How do you approach email notifications

Define individual email and collective email standards here.

It is important to identify the recipient type - SAP Inbox of External email client.

The customer may not want to flood the user's inbox with individual emails, in such a case, Extended Notifications are the answer. Define the EN standards, frequency and generic Header and Footer text standards.

There will be instances where priority individual emails may be required. It would be good to categorize them here and define generic rules guiding such emails.

Helpful Links:

Basics on Extended Notifications

SAP Help on Extended Notifications

Special Thanks to @Jocelyn Dart

Now you may move on to  Workflow Development Standards posted here on SCN.