The Top 10 Mistakes made by Workflow Beginners

1. Trying to muddle through workflow using just your ABAP skills

I got my start in workflow back in 2004 when our ‘workflow guy’ left suddenly, just before an R/3
implementation go-live.

I confidently volunteered to take over, expecting to use my ABAP skills to ‘debug’ the workflow log and
figure out how it all fit together. Ridiculous of course – I’d have more luck dissecting a cat. Within 2
weeks I had booked myself on an (excellent)  1-week SAP workflow course run by Paul Batey.  And then
the scales lifted from my eyes.

I realised that workflow is more about ‘concepts’ and ‘configuration’ than it is about ‘code’. Do not
attempt to mess with it if you haven’t done the SAP course (or at least partly digested the Workflow
Book).

2. Confusing workitems with emails

A very common conceptual  error. Put simply, a workitem is a single piece of work – typically a decision
task – that can be viewed from multiple inboxes, and disappears as soon as one agent processes it.
Workitems can only be sent to SAP system users.

In contrast, emails are typically flat information items. Multiple copies are made and sent separately to
inboxes. They remain in each person’s inbox until individually read or deleted. Emails can be sent to
anyone.

3. Not executing SWU_OBUF before testing your workflow changes

 
I sometimes hear that workflow is ‘flaky’ or ‘unpredictable’. And it certainly is – if you have no
understanding of how buffering works.  But don’t worry: you only need to remember to run transaction
SWU_OBUF before executing a workflow that has been changed.

This applies during development, but also in Test or Production systems after a workflow has been
transported in. The whole buffer is refreshed at midnight.

4. Flooding users’ inboxes with hundreds of workitems

I’ve learnt the hard way that not all approval / decision processes are suited to workflow.  If hundreds of
items are generated per day for one process, it’s probably better to handle them via a report instead.

It may just be a psychological thing, but users react violently to inboxes that they can’t possibly clear
(often compounded by a torrent of reminder emails).  They either stop using their inboxes completely or
clamour to get the workflow switched off.  No news is better than a tsunami of bad news.

 
 Copyright (c) 123RF Stock Photos

5. Not changing the default ‘Receiver error feedback’ setting in SWEQADM

If you start a workflow via an event, and something goes wrong  (e.g.  a mandatory parameter is
missing), the default  SAP response is to deactivate the linkage  between the event and workflow.

Yes, you read that right; and yes, it is DISASTROUS. Any subsequent events are lost forever, until you
realise what happened. Then you have to scramble to fix the problem, transport it to Production, and
reactivate the linkage.

In SWEQADM, the setting should instead be ‘Mark linkage as having errors’. This means that the linkage
will not be cut, and the events will be stored until they can be safely delivered later.

 
Jocelyn D. explains it all perfectly here .

6. Starting workflows directly from a program, instead of using events

I have visited many sites where WS* workflows (and even TS* standard tasks!) are started directly by a
call to SAP_WAPI_START_WORKFLOW. Bzzzt. It is far better to trigger workflows using events.

There are millions of reasons for this, but at the moment I can only think of five:
– you can easily switch a workflow on/off (even in Production) by (de)activating the event linkage
– you can easily switch from an old workflow to a new one, by manipulating the event linkage
– you can choose new workflows to be started by the same event
– if a workflow doesn’t start for some reason, you can examine the event log (SWEL)
– there are no authorization issues with starting workflows

7. Falling behind in the housekeeping

 

It is wrong to assume that if users are not reporting any problems, then the workflows must be
humming along. You have to be proactive and go out looking for errors, especially when a new workflow
goes live.

We reckon there should be zero tolerance for SWI2_DIAG errors. At some sites we have found hundreds
of them, and dozens (re)occurring every day! Transaction SWI2_DIAG should not be considered a tool
for error handling, but a bucket of last resort.

Copyright (c) 123RF Stock Photos

Go ahead now: check SM58, SWI2_ADM1, SWI2_DIAG, SWEQADM and SWEL.

8. Using internal function modules (and tables) instead of SAP_WAPI*s

 
A common question posed on SCN runs along the lines of: what table holds the workflow container
values? Who has sample code for function SWE_EVENT_CREATE?  Bzzzt  (again). Developers should not
be messing with internal SAP function modules or tables. These could be changed on the next release,
which means your code may stop working.

Instead, use a WAPI. These are the SAP workflow equivalent of BAPIs: function modules that provide a
documented service, with an interface that is guaranteed not to change. For example:
SAP_WAPI_CREATE_EVENT, SAP_WAPI_READ_CONTAINER, SAP_WAPI_GET_WI_AGENTS.

9. Not putting enough information in the workitem text

The three ‘R’s of workflow are that work lands on the desk of the ‘right’ person at the ‘right’ time, and
that all the information they need to make a decision, is ‘right’ there at their fingertips.

For example, when approving a leave request, the supervisor might need to know the employee details,
their current leave balance, team leave requests for the same period, and so on.

A good workitem text contains all – yes all – of this information.  The user shouldn’t need to go
anywhere or click anything. (Tip: using webdynpros to render workitems makes rich displays a lot
easier).

 
A comprehensive leave approval workitem

If that all seems a bridge too far, at the very least provide hyperlinks to all the relevant business objects. 
This means the information is only one click away.

Too often I see workitems with telegraph-style texts like: ‘Please approve leave request #45 for
USRICKB’. The poor users are left to track down the details on their own, causing frustration and delay.

10. Agreeing to develop custom workflow reports

This is one of my pet hates.  We get called in to ‘fix the workflows’ and it turns out that the main
problem is actually with a dodgy workflow report .
 

In almost every project, managers request a ‘Z’ report so that they can track the progress of (say) a PO
through the approval process. They want to know: Who has it in their inbox now? How long is it taking?

If you, as a workflow developer, cave in to these requests, you will soon be up to your armpits in Z tables
and update BADIs. But all this pain adds no value at all.

I try to push back and demonstrate that all the reporting they need is covered by GOS, SWLO, SWI1,
SWI2_FREQ and (for more detailed analyses), BI. Once familiar with these tools, they can use them for
reporting on any workflow.