Skip to Content
Author's profile photo Ronen Weisz

A few workflow stories

If you worked in workflow for a few years I’m sure something like this has happened to you, one day, usually a few mounts after starting to use a workflow, someone storms into your office all angry and shouting: “How could this have happened?!, the workflow system isn’t working! How did a temp worker sign a million dollars contact!”

Luckily there are workflow logs, and answer is usually somebody forwarded the approval decision workitem, worst case I have seen, and I didn’t believe this myself at first was: the CEO forward to a VP with the saying “have a look at this”, VP forwarded to a dep. Head, dep. Head to team leader, team leader to a temporary employee who looked at the contact and said “this looks fine to me” and approved the workflow task! And it was a million dollars contract…

Best suggestion, limit the forwarding options if possible by using the s_wf_wi  authorization object and leave the task general and not the forwarding not allowed classification option so you can easily forward the workitems if needed. And relax, the log usually are very detailed and useful. Only place where the logs fail is substitutions, which are not logged in the system…

A few months later in the same project I had this discussion:

“Workflow batch disassembled all the kits in the system!!!”

“What do you mean? It’s a system user; it doesn’t go around disassembling kits in the system for its amusement”

“Maybe there is an error in one of the workflows?”

“We don’t have a workflow for kits”

“But the change documents show WF-BATCH as the user!”

Now, after a bit of searching, we found that a function module that was connected to one of the events had an error that caused it to disassemble instead of the kit it was supposed to, all the kits in the system (forgetting to check if the table is not empty before calling a select ‘for all entries in’). Only way I can give to solve this: change the RFC used by non-workflow function modules in the event linkage, mistakes will still happen, but they will not come running for you when they do.

This was a forwarded reply mail for one of the decision task extended notification mails send by the system with the subject “Purchase requisition is awaiting your approval”:

“Who is this workflow guy? And how dare he give ME orders!”

Funny, right? Might have been funnier if it wasn’t the CEO 🙁 now he wasn’t supposed the receive the task but one of his department managers, well the department manager retired and the next level up the org structure is the CEO. We removed the mail from his user and placed a block on the mail server… and if we’ll get the time we’ll also implement note 1865151 – WF notification: Subscription with SPA/GPA user parameter.

A friend of mine once told me that he didn’t consider a you to be a developer a until you caused a server to fall, well I did once (o.k. three times, but in the span of one hour and it was the same server… at least it was a development server), now you ask you can a workflow take down a server? Well surprisingly easily. Once you remember that a running workflow takes a dialog process from the server and most servers don’t have too many of those since they don’t usually need to have a lot – think about it, how many users are pressing ‘enter’ at the same time?

What I did was to use a raise event step to raise the starting event of the same workflow… in a loop… which caused the number of process taken by the workflow to increase exponentially with every workflow raising more and more workflows and never ending, guesses on how many second did it take the server to go down once I ran the workflow in a test mode?


Luckily I worked with a very understanding and capable basis admin and she raised the server up in no time and with no data lost (1-st time “This can’t be, workflow? cause the server to be stuck?” 2-nd time “o.k. it was the workflow” 3-rd “really, this time I fixed it”).

Now go, prove that you are also good workflow developers, take servers down!

Just kidding…

Use an IDES server 😉

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Rick Bakker
      Rick Bakker

      Great stories, thanks!

      What is a "kit"??

      Author's profile photo Ronen Weisz
      Ronen Weisz
      Blog Post Author

      A tool kit for example - hammer, 10 nails, 2 screwdrivers etc. I think they when maintained as bills of materials in the system, they could be stored as 1 toolkit or as all the components separately. And when a warehouse worker did something they ware disassembled to the components of the tool kit.  

      Author's profile photo Modak Gupta
      Modak Gupta

      Good One!


      Author's profile photo Susan Keohan
      Susan Keohan

      Hi Ronen,

      These are stories that are all too familiar to some of us who have been in the workflow trenches for years.  Fortunately, we can use them to learn - Forwarding, emails, and general suspicion of what that WF-BATCH user is doing in the background are all part and parcel of good workflow design and more importantly, user education!

      I bet you won't ever raise an event in a loop again, will you?  (I know I won't!)


      Author's profile photo Ronen Weisz
      Ronen Weisz
      Blog Post Author

      I agree, they are a very good way to learn and no, haven't used a event in a loop since. did have some other moment of wondering how the server is still working... they must be building the things better lately 😉

      Author's profile photo Joao Sousa
      Joao Sousa

      The problem is not with the forwarding, the authorization logic should be outside the workflow. Sure he could receive the approval workitem, but he shoudn't have the autority to actually approve the document.

      Author's profile photo Ronen Weisz
      Ronen Weisz
      Blog Post Author

      You raise an excellent question (good question = a question I know the answer to / excellent question = a question I have a blog for My (workflow) troubles with authorizations ) since there are many ways authorizations can be set up in the organization.

      For example, after they calmed down, the managers in the organization in which the temporary worker approved the CEO's workitem still wanted to be able to forward workitems and didn't want to limit their authorizations. however they did want me to change the task settings and no longer set it as a general task, so they could forward it only to other approvers. 

      Author's profile photo Murali Krishna
      Murali Krishna

      Nice Stories.... 🙂


      Murali Krishna.

      Author's profile photo Harsh Bhatt
      Harsh Bhatt

      Hey Ronen,

      Thrilling encounters 🙂

      "Who is this workflow guy? And how dare he give ME orders!" Lol. . Funny instance. Reply would be Sir, how dare he gave order to you? We will definitely find out who this guy is? 😛

      Best Regards,


      Author's profile photo Mike Pokraka
      Mike Pokraka

      Development server? Try taking down the production system of a large multinational 😏

      Similar scenario, WF had a start condition 'initiator <> WF-BATCH' to ensure it wouldn't respawn itself. One fine day a diligent Basis person noticed a strange user "WF-BATCH" that didn't fit their naming convention and took it upon themselves to remedy the situation. Boom!

      Since then I always check for 'user type = background' instead of a real user name.