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
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 firstname.lastname@example.org,
I suggest a sender address like email@example.com.
To activate the automatic notifications
you must do three things:
- Plan at least one batch job to run the e-mail notification report
at regular intervals.
- 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
- 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
||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
||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
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 http://service.sap.com/webflow/.
Release 4.6C, e-mail steps were created using a wizard instead of a dedicated
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
restriction does not apply to Enterprise Buyer Professional.
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 firstname.lastname@example.org.