Skip to Content

Here are ten more common mistakes made by SAP workflow beginners. An earlier blog discussing the numbers #1 – #10 can be found here.


Have a laugh at my missteps, and make sure you don’t repeat them!

11. BOR: Referencing Z subtypes instead of the supertype


This has to be the most common beginners’ mistake, and yet is perfectly understandable.


If you delegate a BOR object (say BUS1006 – business partner) to a sub-object ZBUS1006, you should still always refer to ‘BUS1006’ in your workflows, tasks and event linkages.


That’s right: ‘ZBUS1006’ should ONLY be used while creating the BOR object and setting up a subtype.


Otherwise: nunca / never / nimmer / niemals / aldrig / jamais!


event linkage.jog.JPG

Don’t do this


Here are some of the reasons:

  • when you search for workflow instances that use object BUS1006, you now have to also search for ZBUS1006
  • when you see an explicit reference to a Z* object, you don’t know if it has been copied or subtyped
  • it also presents difficulties when searching through an alphabetical list of events (Z* is a long way from B*)
  • if you only ever refer to ‘BUS1006’, you can easily switch to a new subtyped object (e.g. ZBUS1006V2) and your workflows won’t miss a beat..


12. Not catering for all outside events


This is a blunder I have made many, many times. Just because you have built a great workflow for approving (say) leave requests, this doesn’t mean that users will instantly change their habits. No, they will still get desk visits, and they will still approve the leave request through the old SAP transaction.


If your workflow doesn’t recognize that this has happened, then you have a big problem. Users will ring, asking you why they have to approve something twice; or the workflow will go into error when it tries to change a request that is already approved.


So you need to consider all possible terminating events – ‘Approved’, ‘Withdrawn’, ‘Changed’, ‘Deleted’ etc.


Functional specifications rarely mention these scenarios, so it’s up to you to include them.



13. Not setting deadlines based on the factory calendar


When a business analyst specifies that they want a reminder sent after 5 days, they usually mean 5 working days – weekends and holidays don’t count. It seems obvious, but is often missed.


To implement this you need to specify the use of a factory calendar in your workitem deadlines.  The workflow book shows you how.



Copyright (c) 123RF Stock Photos



Even if your business runs 24/7, it still pays to use a factory calendar to cover all eventualities – e.g. future changes or Christmas shutdowns.


Be careful though – if you choose a custom factory calendar make sure it is correct and maintained well into the future. Otherwise – as reported in SCN – your workflows will stop dead when the calendar stops.



14. Over-complicated workflows


When I arrive at a new site, the first sign of trouble is a workflow definition that looks like a tangled ball of spaghetti.




Pasta Chikatetsu (source:


It’s pretty rare that all this noise and fury is really needed to implement a mundane business process (such as PO approval).


Typically, such workflows contain:

  1. A string of container operation steps, which serve as ersatz initializations
  2. Numerous activity steps that do nothing more than call a method to ‘get’ a value (e.g. a user’s email address)
  3. Unnecessary Sendmail steps
  4. A long list of workflow container elements that, really, are just object attributes
  5. A sprinkling of undefined steps (why oh why?)



Justify your existence


Does this sound like one of the workflows at your site? Here’s how to clean it up:

  1. Initializations: use the ‘initial’ tab on the workflow container element instead
  2. Use object attributes (as explained further in #12)
  3. Delete SendMail steps that simply warn the user of a workitem. Use Extended Notifications instead
  4. Again, use object attributes
  5. Delete delete delete!


And once you’ve done all that, consider trashing the whole thing. 😎


In my experience, workflows are often built ‘on the fly’, as requirements are drip-fed or regularly changed. Once you finish the build, it’s worth considering whether to redesign from scratch.


Why? I like to think of a workflow definition as a LEGO(tm) house, where the tasks/steps are LEGO(tm) blocks. It’s no problem breaking it all down again, just to see if you can design something sleek and elegant using the same steps.


Simplicity is so underrated.


My first workflow



Small, sleek & reliable


15. Using ‘get’methods instead of attributes


This item ties in with #14. It is a common mistake made by folks who are used to procedural programming and not so comfortable with OO concepts.


Does your workflow have a step called ‘Get User Name’, based on a method ‘GetUsername’, which fetches user data and stores it in a workflow container called ‘Username’? Which is then bound to a task container element ‘UserName’, just so that it can be used in the workitem text?


Sounds just like a traditional ABAP program 🙂


All this complexity can be avoided if you instead define a (virtual) attribute called ‘Username’ that is automatically populated when the (‘UserID’) object is instantiated. The workitem text can then just use ‘Userid.Username’.



Note: Of course, you have to use your judgement in this. If the determination of an attribute is very expensive, you may not want it executed every time an object is instantiated. In this case, a GET method might be the best approach.




16. Allowing multiple copies of the same workflow to be started for the same object/event


Very typical beginner’s error. I can’t believe we didn’t put this in the top 10.


You create a workflow for approving changes to a PO. It gets triggered when they change a field from ‘Ted’ to ‘Fred’. But should another 3 workflows be triggered if (before approval is granted) ‘Fred’ then becomes ‘Ned’, then ‘Ed’ and finally ‘Mildred’? Uh, no. Users hate this; which one should they approve?


You could set a ‘check function’ on your event linkage, so that no new workflow is started if an active workflow already exists for the same object. Or, when a change occurs, raise an event to terminate the existing workflow and start a new one.



17. Panicking when you see ‘No Agent Available’ in the workflow log


Don’t worry – it doesn’t mean that the workitem can’t find an agent. It just means that no one has started processing this dialog workitem yet.


Perhaps a better translation from the German would be ‘Not yet started’ or ‘Waiting to be processed’.


NOTE: In transaction SWIA (Process Work Item As Administrator) the text is displayed as ‘No Current Processor’.

Don’t worry about it, be happy.


18. Using dummy wait steps of arbitrary length


Some workflows are punctuated with wait steps – dummy steps that call a dummy method that has an ABAP statement like WAIT UP TO 100 SECONDS in it.


Apart from being inelegant, you should question why a ‘wait’ is required and whether 100 SECONDS is long enough. Or perhaps too long. Wouldn’t that depend on how busy the system is? And might it not change over time?


Typically a ‘wait’ step is inserted because you need a process to finish before you can continue – for example, the business partner has to be fully created before we can change it. In cases like this, a ‘wait for event’ step might be more appropriate.


Another option – e.g. in locking scenarios – is to use temporary exceptions.



19. Paying lip service to OO design


I sigh loudly when I see custom events with names like ‘StartApprovalWorkflow’.  That name does not describe a real ‘event’ in the life of a assessment document.  (And it leaves open the mystery of where this event might be raised…)


In contrast, here are some real-life object events: CREATED, CHANGED, REJECTED. If you want to start an approval workflow, you should figure out which event(s) should trigger it, not invent a bogus one purely for workflow purposes.


For example, if an assessment needs approval when it’s CREATED or CHANGED, then you can simply link the approval workflow to these two events (via SWE2).


Similarly, the methods of an object should represent ACTIONS on that object. Don’t shoehorn a ‘Sendmail’ method onto a SalesOrder object, just because you can!



20. Developing custom programs to change workflows / workflow containers


This chimera comes up fairly regularly in SCN – a misbegotten idea to write a report that will automatically approve / forward / obsolete some outstanding workitems. That’s bad enough, but much much worse are programs that seek to ‘pop the bonnet*’ and directly update container values from outside the workflow.

Good luck trying to understand your workflow log, once programs like that start messing with it!


If you feel you have to resort to such measures, then you probably need to study up on workflow features and design principles. Pretty much all of the above can be handled through modelled deadlines or terminating events.



Paul Bakker


*North American readers might say ‘pop the hood’

To report this post you need to login first.


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

  1. Jocelyn Dart

    It’s great to see you blogging so often Paul!

    As well as temp exceptions, I like pre-conditions as another alternative for #18 these days as well.

    So much more efficient than dummy wait steps!

  2. nabheet madan

    Thanks for the blog.. All points you have mentioned in the blog are nice… Specially point 20 is very very common. Plus i like point 15 🙂

    thanks once again

  3. Susan Keohan


    Thank you so much for putting this list together!  I am eagerly looking forward to the next installment.  Regarding our recent conversation on the use of SAP_WAPI_WORKITEMS_TO_OBJECT – it clearly is of use to prevent #16 from happening. 

    Re: #15 When I was a n00b, it seemed to make sense to have methods getting values and storing them in the container.  As time goes on, you may find that just getting that particular value is no longer enough – username morphs into the username and their email address, and their office location, and their manager, and so on.  This is why I (judiciously, I hope) often end up using SWC_CREATE_OBJECT to instantiate say, USR01DOHR, as a subobject – and get rid of all the separate ‘gets’ that have grown over the years. 

    Thanks again for some wonderful Monday Morning reading.  Bookmarking this, for sure.


    1. Sreekanth Krishnan


      Excellent blog. Till this point I was assuming that using an arbitrary wait is a good approach. You have changed my mind.. Thank you so much.


      You guys are the masters of this workflow forum. The amount of knowledge that is being shared by you folks is enormous. Thank you so much.



  4. Swarna Latha Padala

    Good blog Paul.

    Every point mentioned is so valid!

    I have seen workflows growing tangled, and complicated, just because nobody wants to remove an obsolete branch or re-design to make it sleek.

    Thanks for putting this together.



  5. Anjan Paul

    Great blog Paul as usual.

    One thing may be added. Lot of time we generally not checking the Change document. Instead of that we directly User Exit to raise event.

  6. Murali Krishna

    Thanks a lot for sharing your experience and it is changed my way of thinking when handling workflows. Eagerly waiting for your forth coming blog… 🙂 🙂

  7. nithin B

    Great Blog post…   to be genuine i made few mistakes from the above list 🙂  when i was the Beginner to the Workflows.


Leave a Reply