Expand +



"Would You Care to Check Your Workflow Inbox?"

by Alan Rickayzen | SAPinsider

July 1, 2002

by Alan Rickayzen, SAP AG SAPinsider - 2002 (Volume 3), July (Issue 3)

Have you noticed that some slightly overworked managers in your company consistently miss the items in their workflow inbox? Often they’re the ones who receive work items only occasionally, and don’t have the time or incentive to check their workflow inbox on a regular basis.

In this column, you will learn how simple it is to send gentle e-mail notifications to workflow participants, informing them that they have new work items (workflow tasks) waiting for them in their workflow inboxes. And once you get started, you can even tailor these e-mail notices to deliver extra benefits to your workflow users.

This technique does not deal with generating notifications from inside the workflow (i.e., to inform interested observers of important milestones reached as the workflow progresses). To take care of this, create e-mail steps1 in the workflow definition using the Workflow Builder.

Prerequisites for E-mail Notification

The beauty of this technique is that it works no matter what type of workflow inbox the frazzled manager is using (e.g., a Universal Task list in the Enterprise Portal, Microsoft Outlook, Lotus Notes, a Web inbox, or the Business Workplace). It is also independent of the workflow used, so you avoid modifying any workflow definitions. Furthermore, by sending e-mails, you reach everyone, including extranet participants, regardless of which e-mail client or portal is used.

Prerequisites for e-mail notification are:

  • E-mail connection to the SAP component. An SMTP connection is included in the 6.10 SAP Web Application Server. For earlier releases you should use SAPconnect for the SMTP connection (or the connection to Microsoft Exchange or Lotus Notes).

  • The workflow background user (WF-BATCH) must have an e-mail sender address configured in user maintenance (transaction SU01). The domain of this address must be different from the domain that it is sending to. For example, if you will be sending messages to, I suggest a sender address like

To activate the automatic notifications you must do three things:

  1. Plan at least one batch job to run the e-mail notification report at regular intervals.

  2. Activate the notifications on a per-user basis. This is done on a subscription basis so that users can opt in or out of the e-mail notifications as they choose. The e-mails may be regarded as a friendly helper or an annoying intrusion — this is a very subjective matter — so using a subscription mechanism makes good sense! You can fall back on deadline management to ensure that the work items are completed on time.

  3. Maintain the e-mail addresses of the users so that the notifications can be dispatched.

Step 1: Configuring the Batch Job

The notification dispatching report (RSWUWFML, included in the workflow system) takes care of both tracking the work items and sending the notifications. This report was developed in response to a development request from the Workflow Group at ASUG (a tribute to this group’s foresight and influence). Note that SAP Markets Enterprise Buyer, a component of mySAP SRM, behaves slightly differently, as you will learn later, and has its own version of this report (RSWUWFMLEC).

To plan the batch job for the report, simply set up a report variant and set the report as a periodic batch job, as shown in Figure 1. Each time the batch job runs, it searches for new work items (created since the last run) and sends notifications out for the new work items. This means that only one reminder is sent out per work item, irrespective of how often the job runs. The job suffix (e.g. 2, as shown in Figure 1) allows you to plan the job several times concurrently and is usually used in conjunction with the task filter parameter.

Figure 1 Setting the Parameters of Your Report (RSWUWFML)

For example, you could plan the job to run with all common workflows (specified in the task filter) at midnight every night, but plan a concurrent job to run for one particular high-priority workflow definition every five minutes. The two report variants should each have a unique job suffix (e.g., 2 and 3) so that they run independently of each other. This enables the high-priority workflow notifications to be dispatched almost immediately at very little performance cost, thanks to the task filter.

You can also use concurrent planning to have one job send notifications every hour and another job to send weekly reminders about outstanding work items. To do this, plan the second job to run once a week with the same task filter (if any) but a different job prefix to ensure that a second (weekly) notification is generated.

TIP: We’ve found that weekly reminders are most effective — and get the most attention — when they do not arrive on a Monday.

The rest of the report parameters are fairly straightforward. You can configure your own text and specify that only a summary notification is sent to each person, or you can arrange for an individual notification to be sent for each work item. Specifying individual notifications can be intrusive, since the users may receive several e-mails all at once. However, because the text of the e-mail includes a description of the work item, this can be useful for high-priority workflows where the user can see, at a glance, whether it is urgent (e.g., a customer canceling a large order as opposed to a small one).

Do not specify anything in the data for an individual run, otherwise the previous results will be ignored. This would cause notifications to be sent for all pending work items, not just the new ones. This frame is intended for testing purposes, when you call the report directly as opposed to a batch run.

Step 2: Subscribing to Notifications

To subscribe to the notifications, each user will configure an auto-forwarding address using their Business Workplace settings (transaction SWBP) or the user’s Enterprise Buyer attribute settings, where applicable.

NOTE: Although the auto-forwarding address uses the Business Workplace setting at this point, it is only used to determine whether notifications are required (i.e., who is subscribing). It is not the address where notifications will actually be sent.2 (See Step 3 for more on setting the actual e-mail address.)

Configuring the auto-forwarding address can be done once, on behalf of all users, with the help of a batch input report, which you run when you are setting up the system. But take care — this batch job may be run only once.3 Any changes after that time will be done by the user and not the administrator.

When a user wants to unsubscribe from the notifications, he or she can simply disable the auto-forwarding or change the Enterprise Buyer attribute settings.

Step 3: Specifying the E-mail Notification Address

In all SAP components, including R/3, notifications are automatically sent to the home address specified in the user’s address configuration (transaction SU01). The one exception is in the Enterprise Buyer, where attribute settings specify both the subscription and the e-mail address.

The complete cycle is shown in Figure 2.

Figure 2 Delivery of Work Item Notification to Users

Improving the Effectiveness of Notifications

Once you start using e-mail notifications, you will quickly learn how they can be enhanced even further to encourage optimal participation by your workflow user. For example, you might include a URL to an intranet FAQ that describes how to specify who will fill in when the user goes on vacation.

If you would like to learn more about creating e-mail notifications like the ones described here, refer to service note 131795, which also provides more details on notification reports (RSWUWFML or RSWUWFMLEC) and their pre-release availability (standard in all mySAP components and standard in R/3 since Release 4.5).

If you are a registered user and are looking for general information on SAP workflow visit

1Before Release 4.6C, e-mail steps were created using a wizard instead of a dedicated step type.

2Exceptions to this are systems based on Basis 4.6B or earlier. The home address is not available in these systems, so the auto-forwarding address is used instead.

3This restriction does not apply to Enterprise Buyer Professional.

Alan Rickayzen is the Product Manager for WebFlow. He has been with SAP since 1992 and in data processing since 1988. In 1995, he joined the SAP Business Workflow group, performing development work as well as consulting for various major US customers, and as a result amassed a good technical knowledge of the product. In 1998, he moved to the area of workflow product management. The author is coauthor of the book Practical Workflow for SAP and may be contacted at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!