// you’re reading...


Workflow Email Bug – Workaround

Some time back I was working on a RedDot project for a Local Government based in Melbourne, Australia where we were required to create 52 (crazy I know!) separate workflows to manage content within the site – each one corresponding to a specific department/internal process within the organisation.

Some of these workflows were quite complex – having up to 5 separate release steps before the content was finally published to the live site. Emails were automatically sent to the appropriate user group whenever:

  1. A page was waiting for release
  2. A page was rejected
  3. A page release did not occur after a given time frame (i.e. escalation)

Common to all of the workflows was the Grand Poobah – ‘Site Adminstrator’ group who were responsible for releasing content in the final workflow step. Site Administrators also had the ability to bypass all workflows whereby any changes they made did not have to be approved by any other users. This was achieved by setting exceptions for the Site Administrators at every workflow step.

Once we set up all of the required workflows (using RQL as there was no way I was going to manually create them!) we came across the following bug:
Whenever an Admin created and/or changed content within the site, a ‘release’ notification email would always be sent to the group responsible for releasing pages in the first workflow step. This would occur even when the Site Administrator group was selected as an exception in the first workflow step.

It appears that RedDot sends out the email before actually checking the first release step for any exceptions. This was causing a great deal of confusion for editors as they were being prompted to release pages that didn’t need to be released!

Since it can take ages for any of these bugs to be fixed in future RedDot software releases (i’ve waited up to 2 years to get bugs fixed), I came up with the following workaround to fix this problem: Introducing the Faux Release Step!

  1. The first node you create under the ‘Page Created’, ‘Page Changed’, ‘Page Deleted’ etc.. nodes must be a ‘Release’ reaction
  2. Give it a suitable name to identify what it is e.g. Skip First Step
  3. Under the release settings, select any group from the list of users/groups responsible for releasing the pages. (it makes no difference which group you select!)
  4. Click on the ‘Exception’ link and select ‘Everyone’ from the list of groups/users.
  5. Click OK to save your changes.

Under the faux step, you can now create all of the required steps/reactions for the workflow as per normal.


The faux step simply skips the process directly to the next workflow step and eliminates the ‘dodgy’ notification email from being sent. Users will be none the wiser that this step actually exists.

Check out my blog for more RedDot CMS and Workflow articles.

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

About the author:

Kim Dezen Kim Dezen is a Senior RedDot CMS (Open Text Web Solutions) CMS Consultant, Developer and Freelancer. Part time DJ and obsessed music / vinyl junkie. Follow me on Twitter: @kimdezen                  Check out my blog: http://www.kimdezen.com for all things related to Red Dot, SEO/SEM and Web Development.


5 comments for “Workflow Email Bug – Workaround”

  1. I don’t think it’s accurate to refer to the behavior you saw as a bug. In your situation, the “Page Changed” event had two reactions: send an email and release necessary. These actions happened concurrently and independently of each other. The exceptions on the release necessary reaction do not and should not affect the email reaction.

    That said, I understand there is a business need to tie the email and release necessary steps together into one reaction, and while there may be more the software could do to help with this, the way it works now is more a shortcoming than a bug.

    As a personal preference, I find it’s better not to send emails immediately on page changed, etc. Rather, only send emails after an escalation period. This reduces the inbox clutter for users who log into the system regularly but keeps the lazy users on their toes.

    Posted by Eric K | May 20, 2009, 5:35 am
  2. Great post, Kim. We haven’t run into the problem where the email notifications are anything more than annoying for excepted users, but something else in your post caught my attention.

    I would be interested to know more about he RQL script you use to create the workflows. Do you work out the workflow details in XML or Excel? Would you be willing to share your process (if not your code) with us?

    I’ve got a client coming to us with 75 (75!) workflows in their project. We’ll try to trim that down a bit, but if we’re redefining them all, such a script – or a variation – would come in handy.


    Posted by Rob W | May 20, 2009, 2:49 pm
  3. Hi Eric,

    Thanks for your comments..

    I understand that this might not be a ‘bug’ in the system per se, however the users of the system percieve this to be a bug. They receive an email notification – and when they access the CMS homepage, there are no pages waiting for release. Any perceived ’strange’ behaviour that occurs within an application can make users feel ‘uneasy’ about using it – especially if they arent exactly computer savy.

    I have stated that this is a bug, as the email notification is only sent on the first release step if a exception occurs – not any other subsequent steps. Hence the reason why I came up with this workaround.

    All of our clients have requested that they receive email alerts – especially if there is a quick turnaround required to get pages released (e.g. news/media releases etc).

    There is never one definate right or wrong way to implement a workflow.. what works for one organisation, wont neccessarily work for another. As David Brent (The Office – UK) once said “Different drinks for different needs!”

    Posted by Kim Dezen | May 21, 2009, 2:49 am
  4. Hi Rob,

    There is no easy way to automate workflows using RQL. Essentially as there are hundreds (if not thousands) of different workflow permutations, the code would be extremely complex to cater for all instances.

    In order to create the 52 workflows mentioned, it was a mix of manually creating the required settings with code for each workflow – and then executing the script to creating all of the necessary steps, exceptions and the email notication layouts (using consistant naming conventions for all reactions)

    The hardest part of creating workflows with RQL is obtaining the GUID’s of every reaction in the workflows. In order to attach a new reaction (such as an email or release step), you need to obtain the GUID of the parent node.
    The deeper the workflow , the more complex it becomes to obtain the GUID’s.

    Unfortunately i dont have any code that i can give you since it was written specifically for the aforementioned client.

    Posted by Kim Dezen | May 21, 2009, 2:58 am
  5. If anyone is still interested there is a changed behaviour in OTWSMS 10.1 SP2 HF12 that for exception workflow actions emails do not send.

    Posted by Morgan RItchings | April 24, 2012, 12:55 am

Post a comment

Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...