Workflow tips

Creating a step where a supervisor manually assigns an operator to another workflow step.

Use the business object WF_TASK. There are several possible methods to use. Refer to the documentation of the methods to
determine which is suitable for your task. If the task is customized as a general task the supervisor can suggest user names
directly (using wild cards), otherwise the supervisor selects from a list of possible agents.

Hints on transporting workflows.
Patience!
Hints on keeping the HR model synchronized between systems.
Patience!
Troubleshooting when the workflow does not start correctly.
Case 1: When the workflow does not start.
If the workflow does not start this is either because it is not being triggered properly or the workflow definition is not complete.
First determine how the workflow should be started. Directly? Via a customizing table? Via an event? Transaction SWUD offers
intelligent diagnosis help to establish if the flow was started, if the triggering event was fired, if the flow is syntactically correct, if
users are assigned to all the tasks...

Case 2: When the workflow starts twice.
The most probable cause of a workflow being started twice is that it is triggered by two separate mechanisms simultaneously.
For example if the flow is being triggered by an event, check that this event is only firing once. For example, you might find that it
has fired once due the customizing for change documents AND once due to the customizing of status changes. Transaction
SWUD will allow you to determine how many times the event is firing. If it is only firing once, check that the workflow is not
additionally being started directly by a program or customizing tables. Check that the workflow is not customized to trigger on two
separate events.

Sending e-mails from the workflow.
There is a wizard in the workflow editor which will help you send straightforward e-mails from the workflow. The wizard generates
a step based on the business method SELFITEM SendTaskDescription. You cannot modify the business object SELFITEM and
delegate so if you want to do something more sophisticated you should build your own method in another object based on the
function modules SO_xxx_API1. These function modules are the APIs for sending mail and are fully documented. Use the
where-used list to see examples.

Different mechanisms for accessing work items.
In an early stage of the project you should consider the issue of how users are going to be notified off and access work items.
Usually this decision will not influence the definition of the workflows but there may well be organizational issues involved which
you should consider early on. ASAP contains a table of alternative methods. The most common being:

mySAP.com Workplace
SAP Business Workplace (previously the universal inbox)
Microsoft Outlook
Lotus Notes
e-mail
Web Inbox
The e-mail notification can be done automatically without modifying your workflow at all. For tighter integration into other mail
programs you can add form functionality for the workflow steps that will most gain from this.

When to use asynchronous tasks.
Asynchronous tasks are often misunderstood so here's a short note about them. You'll find a fuller description in the online
documentation. Asynchronous tasks only terminate when a terminating event is received. This makes them especially suitable for
tasks where you want to be absolutely sure that the user has done what was intended. The event is usually triggered within the
method itself when the terminating condition is met.

These cases cry out for being implemented as asynchronous tasks:
The user MUST make a change in the business object (e.g. status change)
Post-processing of the method takes place in the update task and it is essential that the workflow does not continue until this
post-processing has fully completed (e.g. creation of a business object)

Some users often perform this task directly from the menu without accessing the workflow system so feedback via the event is
essential to ensure that the workflow continues automatically.

Ensuring that your workflow is robust.
Check that your workflow definition will not stall or get confused when a user performs several tasks in one step. Try not to dictate
the order of processing with your workflow definition unless this is a necessary part of the business process flow. Allow the users
to work the way they want but make sure that they are kept within the realms of the business process framework. Check that the
workflow synchronizes properly with other events. For example, if a purchase requisition is withdrawn the workflow should
terminate immediately and send notifications to all users involved in the process so far. Use deadlines to ensure that the process
runs through on time and that a supervisor is informed when a delay occurs. Often the cause is simply due to illness or vacation
and the task can be performed by someone else.

Documentation issues.
Workflow is dynamic. You can change the business process without sending everyone to be retrained so bear this in mind with
your documentation. Your documentation should be written to ensure that any changes which are made can be done easily and
without upsetting any aspects of the process.

Documentation for the operational user can be made available online with a URL included in the work item description. This
documentation should contain help-line numbers, what to do if you receive a work item intended for someone else (you've left the
department), FAQs, whether the user may create ad hoc attachments (the other users must be aware of the possibility if you want
to make use of this functionality)...

Documentation for administrators should include how to perform periodic health-checks, how to add a new user to the process
(and how to remove someone), what to do when a user is absent for a short period of time, contingency plans, list of counterparts
in different parts of the process if the process is cross-application.

Technical documentation must include a complete catalogue of all workflows, tasks, business objects and roles used in the
process. There is ample room within the system for documentation about the individual components but of particular importance
the events. These must be documented in the system, explaining how they are triggered (E.g. program xxx, status changes...).
The workflow documentation should explain how the workflow is triggered (E.g. event, program...). Subflows should be labeled as
such. Synchronization issues should be documented carefully so that changes can be made without jeopardizing the process

Useful Online Service Notes.
The following notes are continuously updated so that they remain up to date. It's worth checking for updates now and then.

322526 Debugging workflows
217229 Accessing the Consultants forum for SAP Business Workflow/WebFlow
152871 Release Upgrade considerations for workflow
134322 New Workflow Academy - Course TAWF10
131795 Automatic e-mail notifications
125400 Modifying a productive Workflow
72923 Workflow interfaces
72923 Business Workflow Performance