Skip to Content

Vanilla is a nasty flavour for #Workflow events or Help my workflows keep getting turned off!

Final Update: Ok I know I’m a serial blog updater… but this time it’s for the kind of news that leads soccer afficionados to pull t-shirts over their head!  Thanks to the diligent offices our own workflow goddess Sue Keohan and the able support of the Customer Connection team (thanks Daniel-Alexander, thanks Alan) and Product Management teams (thanks Ralf, thanks Joerg) we at last have a good answer to this gnarly old problem.
For more details make sure you take a look at the following SAP Notes to fix this for good (with a couple of manual steps) no matter what release you are on: Linkage: Error Handling Default for Error Handling –  Event: System log written for Deactivation of Event Linkage


Latest Update: You wouldn’t credit it – and I’m seriously considering buying a lottery ticket – but the day after I spent 2 hours explaining this setting to my current customer who has the infamous “deactivation of linkage” setting and why they needed to change it, we had one of these event linkage deactivations occur overnight.  Only because I was still there that day were we able to track down the problem quickly and call out all the emergency procedures to get the event linkage turned on again pronto!
Even so it was another 4 hours of investigation, discussion and experiments to work out how to identify the affected objects and retrigger the lost events (remember evidence of the events themselves is lost), and then a a fun, fun, fun day (NOT) for the workflow support guy who had to retrigger almost 600 events manually.  We were lucky – we identified the problem and got the event working before the main peak period. It could easily have been far worse – another few hours and we would have been talking thousands of events to retrigger. Needless to say they are now quite keen to change that infamous setting…
I like ice cream. I like ice cream so much I even enjoy making ice cream.  It’s easy, it’s fun and it’s delicious.  I love the pure, natural taste of homemade ice cream made from fresh eggs, milk, cream and sugar.  I love the creativity of mashing together wonderful flavours into ice cream: lavender and rosewater; saffron and apricot; rhubarb and ginger wine; chocolate and rosemary. Delicious, and the possibilities are endless! 
But I have a confession to make.  I *hate* vanilla ice cream.  Vanilla ice cream to me is ice cream with all the joy sucked out of it.  Vanilla ice cream is the 40 cent cheap-as-chips soft-serve McDonald’s or Mr. Whippy cone full of artificial flavourings, nasty additives, unwelcome preservatives and with about as much taste as the plastic cones on the front of the Mr Whippy van. ice cream van.JPG[Image courtesy of Stuart Miles /]
A travesty of what ice cream should be.
I also like SAP Business Workflow. I like workflow so much I even enjoy implementing workflows whenever I get the chance.  It’s certainly not easy, but it is very creative, and the challenge of designing a workflow that really meets the needs of the business can even be a special kind of fun.  In fact, I like finding out about the business process as much if not more than the workflow.  Working out why things are done a certain way and what benefit that really brings to that business. Separating out and then mixing together the various design ingredients of deep-seated needs, aspirational wants, tried and trusted habits, and unforeseen opportunities into a hopefully elegant workflow solution. Fascinating, and the possibilities are endless!
But I have a confession to make. I *hate* it when customers tell me they want a “vanilla” implementation.  To me a vanilla implementation is the very antithesis of what a good SAP implementation should be.   To be given all the power of those near infinite variety of options and not to take advantage of them, or to compromise real business requirements for fear of using a provided enhancement spot, is to me a tragedy in the making.
Of course I recognise that budgets and projects are not unlimited, and that scope creep is a perennial problem of most SAP projects, so there is a certain amount of balance needed, but sometimes the “vanilla” approach can really hurt.  Especially when “vanilla” is translated as:
“Don’t touch any of the SAP default settings that we don’t absolutely need to change.  After all the default settings must be the best practice settings too, right?” 
Well, no, not always.

Take workflow events…

For those who aren’t familiar with them, a workflow event is basically just a little alert an application, program, transaction, report, or other workflow can raise to let workflow know that something has happened.  It’s the way the rest of the SAP system communicates with workflow to let workflow knows something has changed.  Workflow can then respond by starting, stopping or resuming workflows, or of course by doing nothing.  One of the main ways events are used is to start workflows, e.g. 
  • Event “Invoice 52000132849 has been blocked”… so let’s start a workflow to get someone to review the reason for the block and sort it out;
  • Event “Purchase order 4500923830 is waiting at release code level S2 to be released” … so let’s start a workflow to get it in front of the designated “S2” approvers
  • Event “New cost centre 10923ABC created” … so let’s start a workflow to notify the interested parties
Most of the time, the linkage between the event and the workflow works beautifully, and the relevant workflows get started, or stopped, or resumed or whatever is supposed to happen when the event is raised.  Every so often, usually when someone introduces a new version of the workflow, or an event gets raised from a new place, or someone does something that didn’t get covered in testing, something goes wrong. 
And that’s when you really DON’T want to be on the “vanilla” setting for what happens next.
Once upon a time a very long time ago (prior to R/3 4.6C – yes that long ago) the default “vanilla” behaviour was that if for some reason the workflow couldn’t be started the default behaviour was “deactivate that event linkage immediately”.   It was assumed something dire had happened that affected every single instance of the event linkage, say the workflow definition hadn’t been activated properly.   But actually the same behaviour occurred if it was simply that occasionally some of the data being passed from the event to the workflow was missing or in the wrong format.
What’s the problem with the event linkage being deactivated?  Well that meant:
  • Any subsequent events would NEVER trigger the relevant workflow
  • And worse, all the events that were raised after the deactivation were lost – unless you were lucky enough to have the event log on (which is discouraged in production for performance reasons) you had NO record of which events had occurred, when or with what data; and NO way toredeliver the events once the problem with the linkage was fixed (even if you did have the event log on).
In a production system this behaviour can be a disaster.  Imagine having trying to track down all the purchase orders that are awaiting approval but don’t have an approval workflow; or track down all the blocked invoices waiting for release but with no-one aware that they need to be released; or track down all the new cost centres that have been created but no-one has been told that they are there and ready to go. Not fun. 🙁
This behaviour was so undesirable most workflow people I know (and that’s quite a number now) classified it as “would be a bug if it wasn’t a documented feature”.
Now this *was* fixed a very long time ago, so why I am writing this blog now?  Because as a workflow advisory consultant I am still going from site to site to site, and finding the old undesirable behaviour is still in place.  Even today as I write this blog I have been at yet another site where the old undesirable behaviour is still unwittingly in place. More often than not, the excuse I am given for this is the “vanilla” implementation excuse.
Why is the old behaviour still showing up from site to site? The way this behaviour was changed was to provide a mechanism for controlling the event behaviour in the event of an error.  This control could be set centrally in transaction SWEQADM on the Basic Data tab in the “Receiver error feedback” field (as shown).  Deactivationlinkage.jpg
If desired the control could also be overridden in specific event linkages in transaction SWETYPV.
Choice is great but there’s a small snag here.  Because it was implemented as a choice, each site could choose to implement one of the new, improved behaviours or stay on the old undesirable behaviour.  Which choice was set as the default? Look again at the screenshot and note the value for the “Receiver error feedback” field… yes, the old undesirable “Deactivation of Linkage” behaviour! Why was this done? Time for a quote from the SAP Library Help itself:

This setting is in accordance with the classic runtime behavior.

In other words, the intention was to try to minimize the disruption as you upgrade from one release to the next, one enhancement pack to the next.  All of which sounds quite reasonable; except when no one liked the old behaviour.

So what are the new options and how do you avoid falling in the same trap?

There are 2 alternatives to “Deactivation of linkage”:

SWEQADM - Do not change linkage.JPG
  1. “Mark linkage as having errors” – This deactivates the event linkage but captures the failed events and all subsequent events until the event linkage is reactivated. 
    • It also provides an easy way to reactivate the event linkage on the Linkages in Error tab of transaction SWEQADM. 
    • Not everyone will agree, but personally these days I prefer this option especially in quality assurance systems, as it tends
      to make you notice design faults in the workflow or the application raising the event much more quickly. 
    • Note that it does require someone to be monitoring SWEQADM regularly to see if events have gone into error.
  2. “Do not change linkage” – For most sites this is the safest option.  Just don’t deactivate the linkage, but capture all the failed events so they can be redelivered.
    • This is a best of both worlds option, especially if your workflow administration is a little lax.
    • At worst, only failed events will be impacted, and even then the failed events can be easily redelivered once the cause has been identified and the problem resolved.
Frankly either setting is a vast improvement on the default setting.
So if you do nothing else as a result of this blog, check what setting is in your system, and if it’s on “Deactivation of Linkage” go and change it to something else.

How do you redeliver failed events?

The Linkages in Error tab of transaction SWEQADM was also provided to show all the failed event linkages, from there you can review and redeliver failed events via the “Deliver again” button.  You can also redeliver events using the Event Browser utility also accessed from transaction SWEQADM to delve into the depths of the events and examine the contents of the event container, which is an invaluable help in diagnosing why the event linkage failed in the first place.

Redelivering events.JPG


For more information try these references:

SAP Note: 1509503: Deactivation of event linkage
Last time someone asked me to make vanilla ice cream I couldn’t bring myself to do it.   We ending up compromising on lemon-scented vanilla – and even then it was  real vanilla with all those tiny black seeds in it.
So maybe next time someone suggests your site should be “vanilla” implementation, perhaps you could point them to this blog and suggest instead lemon-scented vanilla, or at least vanilla with a few chocolate chips…
[Image courtesy of piyato /]
You must be Logged on to comment or reply to a post.
  • Jocelyn,

    This blog should be required reading for all SAP Workflow developers!  Thank you so much for taking the time to put it together.  Sharing your knowledge makes us all richer.

    AND, you can make ice cream for me – any flavor, any time.  YUM.


  • Great blog again Jocelyn. I’ve seen this problem lots and lots…

    There’s another real beauty that I often see… Customers just want the “vanilla” sap standard workflow. These workflows out-of-the-box do not have the “terminate if no agent found” flag set in the rule that determines who the workow task goes to… Typically the customer sets all dialog tasks to General to get them working. Only a slight error later and you get the whole company seeing a general managers performance appraisal for example.   😉

    • Thanks Jason…  suspect it happens a lot more often than is actually reported…

      Yes the mail to all users… that’s a fight for another day that one… we do have some protection in the system these days for the send to all general task agents problem, but it still cuts in if you have used broad ranging security roles as possible agents.  But then there are so many other topics to blog on… like how escalation can be counter-productive, why org structures can be as much a hindrance as a help…

      Would be great to seeing you contributing your own blogs? – I’m sure you have plenty of stories to tell. Any chance you could add that to your 2013 New Year’s resolutions? 😉

  • Thanks Jocelyn,

    We were always looking at the event linkages to find out if it’s working fine. Quite often our workflows used to get deactivated. We had to activate the linkage again and again.

    Thanks for hating.. (well… not liking) the’ Vanila Falvour’.

    We changed the default settings in SWEQADM for “Receiver error feedback” as “Do not change linkage”. We can be at ease now. 🙂

  • A very well described regularly occuring
    problem which was unknow to us earlier.
    But thanks to you now. 🙂 🙂

    And yes, you are right “It happens more
    often than it is actually reported.”

    Really a great BLOG.

    • Thanks so much Himanshu! So glad it helped! Ionly wish more people knew about this before they hit the problem… so please pass the message on.



  • Jocelyn,

    This is a really helpful blog, I am working in workflows for past two years and was not at all aware of this problem. Most of the time, the linkages used to break whenever we move a WF transport and I used to reactivate it manually (without knowing what caused this issue).

    Now, after reading this blog, I have a permanent solution.. Thank you so very much.

    PS: I am going to read all your blogs (I know there are lot of them 🙂 ).



  • Wow, Jocelyn, I just read your update.  That is great news – that customers won’t have to live with vanilla events anymore.

    Yes, SAP WF people are fortunate to still have amazing support from people like you, Alan RickayzenDaniel-A. Heller, Ralf Goetzinger, and Eddie Morris, to name just a few. 

    I hope that someone replies back as soon as they implement the appropriate notes.  It would be a great experience to share.  The before and after?

  • Jocelyn,

    I came across this blog post only now and I love it: for the way it’s written, for the content, and for the way you keep updating it. Fantastic work, and huge thanks! 🙂



  • VERY nice blog!!! Workflow doesn’t often get the attention it deserves. (yeh’s just one of those behind-the-scenes things that just magically works haha). Thanks for putting this together!

  • Hi Jocelyn, This is also very useful to a complete newbie to workflow such as myself.. (background of SD). Our settings are as described in your blog in all 3 environments! Yikes..! 😐 I’m also new to SCN, so not 100% sure how to search for topics.. I wondered if I could be cheeky and ask If there are ways to refresh users Workflow Inboxes, as when they action events direct from the e-mail they are not cleared down… We have some users with 1000’s of old messages…

    • Hi Mark, Glad you found it useful!

      Suggest you ask the question on the SAP Business Workflow forum itself to get a range of opinions. My first question would be why actioning events from the email is not clearing the work items? That tends to suggest a missing reference to a workflow event somewhere.  And there are tools such as transaction SWIA that can be used to logically delete old messages that were stuck due to such design problems.  But best advice is to post a discussion on the SAP Business Workflow forum itself with some specifics so we can solve the cause and not just  the symptoms.



  • Thanks Jocelyn for explaining so nicely.

    Does SWEQADM also holds terminating events with error ?

    The default behaviour in my system is ‘do not change linkage’.

    We are facing an issue where terminating events are not triggered for some standard and custom single step workflow and the workitem is pending in approvers inbox even though he has done the approval. Its happening with sap cats timeaheet workflow task where it failed to deliver COMPLETED terminating event of BO CATS. Terminating event instance linkage exists in SWEINST for receiver WORKITEM.

    I could not find any errorneous events in SWEQADM.

    Is there any specific setting I can use for logging terminating events with error in SWEQADM so that later on I can redeliver them.

    Please assist.

    Thanks & Regards


    • Hi Ibrahim, Thanks for the comments… and yes it does. But I suspect  your problem is that the event is raised without any error – i.e. it’s raised ok but just not found any matching work item subscribing to it.

      From SWEQADM you can redeliver events that have been previously delivered – so that would help.  And also you have the Event Browser where you can examine the event container of the delivered event and perhaps work out why it didn’t match.

      If you want to take this further suggest you raise a discussion in the workflow forum itself.