Skip to Content

This SAP workflow blog – the third in an overly-ambitious series – spotlights the top 10 mistakes made by workflow beginners (aka ‘noobs’).  I can truly call myself an expert in this area, because I’ve probably done them all!


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.


flooded inbox.jpg


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).


leave workflow.JPG

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.



I probably have a few more of these and will put them in a blog later. Please share some of your own pet hates.


Happy workflowing!
Paul Bakker
Hanabi Technology


PS Here’s a followup blog, listing another 10 common mistakes:

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Jocelyn Dart

    Great post Paul!

    May I humbly add:

    For point 7  – Include transaction SWPR to your list and also SWF_GMP.

    SWPR shows by default any errors happened in the last couple of days.  Yes you can adjust the timeframe but all too often everyone forgets.  SWF_GMP shows the count of ALL workflows in error plus a couple of other tidbits, so you can quickly see if your workflow environment is healthy or being neglected. If SWF_GMP times out when you go into it….

    For point 9 – It’s a good idea to:

    a) Do decent texts up front especially subject texts.  Remember that when a user is looking at an inbox this is what they are using to filter and sort the list of work they have to do.

    b) Follow a standard for the subject text at least across all your tasks – so that people who work with more than one workflow get some consistency –  and getting business sign off on the actual texts up front can save you having to rework your workflow later to add 3 more variables they want in there.

    For point 10.  For expert users, SWI14 is an option. They need to be given their object types or classes in a handy cut and paste list, but after that it’s much the same as GOS but gives you everything that’s been happening with an object type, say Purchase Orders, over the specified period. 

    A fantastic list Paul and I see these all the time on sites!

  2. Susan Keohan

    Hi Paul,

    I couldn’t have said it better myself!  One of my (STILL) pet peeves is when people say they got ‘mail’ from SAP and executed it, and then blabbity-blah happened.  It is not mail.  Mail comes to your Outlook inbox.  Workflow delivers (not just mail, cause we can do that!) but executable tasks.

    ST22, SM58, SWi2_DIAG, even SLG1 can help keep the system purring – like a non-dissected cat 🙂

    And customer workflow reports – oh, the pain!  I have had some modest success in pushing the standard WF reporting tools, but only modest. 

    Thanks for #3 out of #73!


    1. Kumud Singh


      Perhaps what I experienced sometime back sounds well with your reply above: I was asked to look into a scenario wherein a mail was triggered to the SAP Inbox of the user in case of a warning message in the transaction and I had to find out how a similar mail could be triggered in case of an error message. Just by looking at the triggering of an email it was assumed that a workflow is involved! As I had expected, there was no workflow and it was our pretty familiar FM SO_NEW_DOCUMENT_ATT_SEND_API1 doing the job.

      I also had a good time ( 😉 ) when ‘mail’ and ‘workitems’ were used interchangably while explaining the requirements. But I think, I succeeded in getting that rectified.



  3. Ashish Sachdeva

    Hi Paul ,

    A Great Bolg For a Novice in workflow and 6th point is really useful , from my current project i will also advice my workflow consultant about same 🙂 .



  4. Sreekanth Krishnan

    Awesome post Paul.

    I have done most of these mistakes myself, in my early days.

    As an ABAP consultant, you tend to do these mistakes very frequently.

    Am sure this will be a very nice document for beginners.



  5. Benjamin Kröger

    Unfortunately, I’ve found this article after I’ve almost finished work with my first Workflow project. Nonetheless, there are some good advices for the next projects.

    May I please say something to point 10:

    Yes, there are many standard reports for the workflow environment, and yes, you should prefer standard transactions to customer’s reports, but mostly, standard reporting transactions are designed for heavy user who are familiar with the system and internal objects. So imho, a Z-Report may be useful because you can make the monitoring and administration of workflows (not of the workflow system) easier. Of course you have to use some more tables, but on the other hand, you can combine functions in one report or one transaction, which are normally scattered over several transactions.

  6. Ragavendran Kanagaraj


    Very nice post.So many mistakes in this i did while starting in workflow works.It surly helps to some one who is giving fresh beginning in workflows.

    Keep rocking dude. 🙂

    Warm Regards,


  7. Anand Pippalla

    Nice blog. Webdynpros for work item display to show all information was a good one. Gives flexibility to pull more info into the workflow, instead of writing logic or using editor to insert &variables&

  8. Hafizul Mollah

    Hi Paul,this is a very good and useful blog and I think we should all keep all these points in mind while doing the workflow related work.

    Just want to share one thing from my experience is that for example the event delivery job is scheduled in every 3 minutes and the testers do submit the request in the portal like Transfer/Comp. change and get the notification number and open the workflow for that from tcode IQS23 immediately to see from the workflow log that whom the worktiem has been sent.

    But as the event delivery job runs in every 3 minutes immediately the event does not get deliver(gap is 3mins) some time immediately so they do contact us saying why the workflow is not initiated in IQS23 so we have explained this thing to them and told them to go to the tcode SWEQBROWSER and deliver the event manually.

    A lot of testers do contact us specially the new joinee.

    And also for our case sometimes after doing some complex workflow development when we do the testing and found the workflow did not trigger then we do a lot of checking.

    So in this case first thing we need to go to the tcode SWEQBROWSER to check has the event got delivered or not.If no then deliver the event manually instead of checking other details.It may save time.



  9. Mohammed Jaffer

    Nice Blog .This is very useful for workflow beginners.Especially it is very important to note point 6 & 8 which helps us in workflow analysis or in case of enhancement.

    Thank you so much for sharing the knowledge.


    M M Jaffer.

  10. Murali Krishna

    Nice blog Paul Bakker.

    Very useful points to every workflow beginner. Your points will be  solution for some queries. 🙂

    It is very good to heard about SWEQADM.

    Thanks for sharing knowledge. Keep posting the good blogs.


    Murali Krishna.

  11. M Santoso

    I have seen too many workflows developed with too many ABAP codes. And points mentioned in this blog are valid.

    And turn ugly at the end with very high cost of ownership.

    Few more points:

    – Missing the whole point of SAP workflow in business (part of business process reengineering)

    – Missing information from workflow log

    – Missing the purpose of workflow-subworkflow (hard to read from workflow log)

    – Missing daily check and health check

  12. Suseelan Hari

    Hi Paul,

    Very interesting about 10 mistakes made by workflow beginners. I liked it very much and pics are awesome. Keep it up! 🙂


    Hari Suseelan

  13. Erik Gouw

    Hello Paul,

    Nice to read your both blogs on this and I agree on most items. However I totally disagree with point 10, as someone said earlier also. Of course you must sometimes say ‘no’ to the business, but in a lot of cases a custom report, (prefferably based on a z-table, which is filled from the workflow, so that it is faster) is definitely of added value. You don’t want end-users messing around with these technical transactions. They need simple reports to monitor the status of a workflow or get an overview of the total situation. Sometimes it can be of extra added vaue to add buttons in the report which trigger events that can influence the workflow.

    I just wanted to say that, my of course compliments for the blog!

    Kind regards,

    Erik Gouw

    1. Rick Bakker

      Hi Erik,

      I agree with Paul on point 10 but I do see your point about end users not wanting to use complicated SAP transactions. However, the use of Z tables in this situation is something I completely disagree with. I have seen people spend 6 months trying to get something like that to work and then having to rip it all out again. There is a basic principle in database management: don’t store the same information twice (aka “The man with two watches never knows what time it is”). If reports are too slow then the problem lies with the report, not with the underlying tables.

      IMHO, of course.


      Rick Bakker

      1. Jerry Lucas

        Hi Rick,

        We are in the process of ‘discovering’ what was done almost 2 years ago, and then we will be re-writing the entire workflow process.  Several of the top 10 and 20, mentioned in this blog, were made here at my current position, and will need to be fixed.

        As it relates to custom Z reports, why not take the time to train the user, so it is not necessary at all.  Once a user learns one report, the others become easier. It is like the old saying, teach a man to fish, and he can eat for life…

        PS. Thanks Paul for sharing this info, very helpful and insightful.

    2. Paul Bakker Post author


      Thank you for your thoughtful feedback, however I must violently disagree with you. I have never found any need to replicate workflow data in Z tables, for the purposes of reporting. The amount of work (and risk) is too great to justify any increase in speed.



  14. kishan P

    I’m a n00bie WF developer and I’ve already made 6 of the above mentioned mistakes (with 2 Not Applicable and 2 did-it-the-right-way). Thanks for an amazing blog. You are such as asset to this space.


  15. Daniel Klein

    Thank you, but I have a question:

    – you can easily switch a workflow on/off (even in Production) by (de)activating the event linkage

    Can you tell how to do this? I always get “system not changeable” in non-dev system.
    Requirement is to deactivate linkage in DEV/QSS system, but activate it in PROD system.



Leave a Reply