Service Pack 2 prevents an on-change workflow from starting itself

Hello all, Stephen here again — I’m a writer for SharePoint Designer. I’d like to tell you about a fix that was included in Service Pack 2 for Office SharePoint Server 2007 and Windows SharePoint Services 3.0. This fix affects workflows designed in SharePoint Designer 2007. Then I’ll show you how to intentionally create a workflow loop by using two workflows instead of one.

Before Service Pack 2, it was too easy to inadvertently design a workflow that triggered itself and created an infinite loop. For example, consider this scenario:

1) A workflow starts when an item is changed.

2) The workflow updates (or changes) the current item (e.g. by using the Set Field in Current Item action).

3) Because the workflow changes the item, it triggers itself.

So if you had an on-change workflow that sends you an e-mail and then updates the current item, you could quickly receive several hundred e-mails in your Inbox.

After you install Service Pack 2 on your server, it is no longer possible for a workflow that starts when an item is changed to trigger itself by changing/updating the current item. This infinite-looping scenario is not possible:

Many people, however, have designed workflows that actually leverage infinite looping. For example, you could design an on-change workflow that loops endlessly on a task item and that sends a daily reminder until that task is marked complete. The workflow triggers itself by updating a Counter column that was added to the list just for this purpose. And the workflow has a rule that stops or “short circuits” the workflow if some condition is satisfied — in this case, the workflow stops without changing the current item if the task Status = Completed. After SP2, this workflow will in effect be broken because it cannot trigger itself.

SP2 does not block infinite loops, which can be useful, but to re-create what worked before you must design two (or more) on-change workflows that trigger each other. Two on-change workflows that trigger each other by updating/changing the current item is a “co-recursion” scenario:

In addition, it is very common to implement a state-based workflow by using several shorter workflows that trigger each other. For example, you might have a list with a Status field and several on-change workflows attached to that list. All of those workflows include a step at the end that updates the Status field. So one workflow triggers several others by updating the Status, and then those workflows look at the value in the Status field to determine whether they should continue running or stop. This state-based workflow is also a “co-recursion” scenario because one workflow starts many other on-change workflows by changing/updating the current item. Service Pack 2 does not block this type of state-based workflow that relies on co-recursion.

Recap

· Before SP2, a single on-change workflow could enter an infinite loop by updating the current item, thus triggering itself.

· After SP2, an on-change workflow can trigger any other on-change workflows by updating the current item, but an on-change workflow cannot trigger itself. So co-recursion scenarios -- including any scenario that implements a state-based workflow by using many smaller on-change workflows -- are not blocked.

· As a reminder, it has never been possible to create an infinite loop by having an on-create workflow create an item in the current list. Every workflow has a property that contains the “workflows I cannot start” — this property is used to prevent looping for workflows that start when an item is created.

· As a further reminder, all of the previous scenarios involve only workflows attached to a single list or library. Infinite looping in cross-list scenarios has never been blocked for either on-change or on-create workflows.

Creating loops before Service Pack 2

This section presents an example of how a single on-change workflow could leverage infinite looping before SP2. After SP2, this workflow will not trigger itself, so the next section presents an example of how to create a loop by using two separate workflows.

Assume you have a task list named Team Tasks, and you want to design a workflow that will send a reminder every day until the task is marked complete.

First, add a column named Counter to the list with a default value of 0.

You need to hide the Counter columns from the list forms (New Item, Edit Item) so that only the workflow can access/update it. Fist, on the list settings page, click Advanced Settings, and then allow the management of content types.

On the list settings page, click each content type, and on the next page click the Counter column. Make the Counter column hidden. Do this for every content type in the list.

After creating and hiding the Counter column so that it does not appear in forms, you’re ready to design the workflow.

The Daily Reminder workflow should start whenever an item is created or changed.

The first step checks for two things: (1) If the task has already been marked complete, the workflow stops. This rule “short-circuits” the loop whenever the task is finally marked complete. (2) If the task is not completed, the workflow checks to see if the due date is in the future (greater than today). If this is true, the workflow pauses until the due date, because you don’t want to send reminders until the due date has been reached.

The second steps again checks whether the task is completed (in case the workflow paused until a due date on the previous step, and the task was completed in the interim). If the task is still not complete, the workflow pauses for one day.

The third step again checks to see if the task was completed while the workflow was paused; if true, the workflow stops.

If the task has not been completed, the workflow (1) sends the e-mail reminder; (2) set the CurrentCount variable by doing a lookup to the Current Item/Counter field; (3) adds 1 to CurrentCount and stores this value in a NewCount variable; and (4) sets the Counter column to the value stored in the NewCount variable.

Basically, this step increments the Counter column by 1 each time the workflow runs, so you can look at the Counter column to see how many reminders have been sent. And most importantly, the “Set Field in Current Item” action at the end of this step is what “changes” the current item, thus causing the workflow to trigger itself and create the loop.

Creating loops after Service Pack 2

After SP2, you can still achieve this looping effect, but it requires designing two workflows that trigger each other (co-recursion) instead of a single workflow that triggers itself.

Here you’ll use a (1) Counter workflow that increments the count and a (2) Worker workflow that actually sends the reminder mail.

1st workflow — the Counter workflow

As above, you need to create a Counter column in the list with a default value of 0, allow the management of content types, and make this field hidden for every content type in the list.

This two-workflow design requires a second column, SendMail, which will act as a flag for the Worker workflow. The default value must be No – otherwise, any change to a task item would cause the reminder mail to be sent.

The Counter workflow will start when an item is created or changed.

The first step checks the task status – if the task is complete, the Counter workflow stops.

If the task due date is in the future (greater than today), the second step pauses until the due date, because you don’t want to send reminders until after the task is due.

The third step again checks for task completion, in case the task was completed while the workflow was paused on the previous step. If the task is still not complete, the workflow pauses for one day.

The final step checks the status again to see if the task was completed during the previous day-long pause. If not, the workflow updates the current item by (1) incrementing the value of the Counter column by one and (2) setting the SendMail flag to Yes (the default value is No).

2nd workflow — the Worker workflow

The Counter workflow above ends by updating (changing) the current item. These updates trigger the Worker workflow, which is set to start when an item is changed.

The Worker workflow simply checks to see if the SendMail flag is set to Yes; if true, the workflow sends the reminder message and sets the flag back to No.

Setting the SendMail flag to No is the change that triggers the Counter workflow above. The Counter and Worker workflows will trigger each other, sending daily reminders until the task is marked complete.

Alternatively, instead of an infinite loop, you can have the Worker workflow escalate the task notification when the Counter column reaches a certain value — say 5 reminders. The following step executes different branches depending on the reminder count. When the count reaches 5, the workflow sends a message to a manager, whose e-mail address you can either “hard-code” into the Send an Email action or retrieve from a list by using a workflow lookup.

You could also have the Worker workflow reassign the task to a different individual or group after a certain number of reminders have been sent. For this step, the workflow reassigns the task to a SharePoint group comprised of team members who are responsible for following up on such escalated tasks.

If you want to end the loop when the count reaches a certain number, also make sure to add a branch to the first step of the Counter workflow – not the Worker workflow. This branch stops the loop when the Counter column reaches 6.

I hope you find this useful.

—Stephen

Comments

• Anonymous
  July 13, 2009
  Thanks so much for posting this. I was pulling out hair trying to work out why my (deliberate) recursive workflow was not firing a second time. Why are these service pack "fixes" not documented, for example in the list of changes linked to on this page; http://blogs.msdn.com/sharepoint/archive/2009/04/28/announcing-service-pack-2-for-office-sharepoint-server-2007-and-windows-sharepoint-services-3-0.aspx

• Anonymous
  July 15, 2009
  The comment has been removed

• Anonymous
  July 24, 2009
  Thanks this is helpful.   Do you know if there is any impact to workflows that start when a new item is created, or more specifically when the item in a list is created by a COMMIT from a SharePoint Designer form?  

• Anonymous
  July 28, 2009
  Hi There, I wanted to know the following: i.    On item create, email sent to xyz. ii.   Xyz checks the list item and keys in information from him. This will be done by a new set of fields in the same list item. Should have mandatory fields for the xyz user. iii.  Xyz completes and submits. iv. On submission another user receives and sees another set of information. S/he keys in the information and proceeds to submit. v.  This process repeats until the workflow ends. Basically, there are a set of users who see different columns based on access control. Is this possible? Thanks Josephine

• Anonymous
  August 09, 2009
  The comment has been removed

• Anonymous
  August 14, 2009
  Hello, Thanks for the post.  After reviewing this, I realized that there is one problem with this solution that is not mentioned.  This is, if the user created his list with the "automatic email" sent to the "Assigned To" for any changes to the list, implementing these two recursive workflows will trigger two (2) background emails to be sent to the "Assigned To" for each updates in the two workflows - one for the counter update, and one for the SendMail update, won't it? Marcia

• Anonymous
  August 24, 2009
  Can I consolidate all the tasks and send one email, instead of sending one email to each task?  How can I achieve this? Thanks RaokChandra

• Anonymous
  September 01, 2009
  We don’t use recursive workflows intentionally – obviously if a workflow starts on change of an item and then changes something in that item it used to recur  and we had to check that so it didn’t loop.  So if SP2 is stopping this it should be quite good for us.   However the error messages SharePoint produces in the log file are very annoying as they make monitoring of workflows very difficult – do you know of a stopping them being produced?

• Anonymous
  September 04, 2009
  Hi, I did every thing above, Howerver i receive this error after the second pause. "The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly." First pasuse: Email is sent Second Pause: Shows the error above Third Pasuse: Email is sent Fourth Pause: Shows the error above Fifth Pause: Email is sent Please, help me

• Anonymous
  September 22, 2009
  Does anybody is be able to get Today column calculated  this -->   [created]+[count] , and then this get update everytime the workflow counter get update and then send the reminder email by comparing in Actions duedate is equal to Today send email [analyst] Regards,

• Anonymous
  September 24, 2009
  Hi all, Nice post... it is giving me light but ...Could you provide more information about how you make'Today' Column  get updated dynamically?   (I am assuming 'Today'  column type calculated such as =[created]+[counter]) Regards, Christy

• Anonymous
  September 30, 2009
  I am actually having the exact opposite problem (on Service Pack 1).  I have a workflow that does a calculation, sets a field to the new value and sends an email to the end user.  The problem is the end user can change the values that go into the calculation, so I need it to recalculate each time someone edits that item.  However, as soon as you set the field, a new instance of the workflow beings because the item was changed.  In this workflow it does the calculation again and sends the e-mail, but because it did the calculation - and did anoter "Set" - the item has now changed, thus creating an infinite loop. So. I'm verrrry happy they have this fixed in SP2, but it's very difficult to get SP2 through change control this year, so I'm looking for a way to prevent the loop.   My next step is to create a 2nd list and store several values from the 1st list.  Then I will compare values in List A to values in List B in the workflow.  If nothing has changed, the workflow will stop before it updates any values.  This should solve my problem, but seems like a tedious workaround. Any other suggestions?

• Anonymous
  October 13, 2009
  Hi Stephen, We are experiencing some issues with workflows not starting on a document library which has been e-mail enabled. I can imagine that the change you described also causes this issue, am I correct? Regards, Yorick

• Anonymous
  October 19, 2009
  Is this also true for e-mail enabled folder? We are experiencing some issues with workflows not start when a new items is added via e-mail on an e-mail enabled library.

• Anonymous
  October 20, 2009
  The comment has been removed

• Anonymous
  November 04, 2009
  Great idea! A lot of fun to do with it :) But is there a similar trick to loop for each in a usermulti?

• Anonymous
  November 15, 2009
  The comment has been removed

• Anonymous
  November 16, 2009
  Stephen......have an issue that I just can't seem to solve. I have implemented your SP2 solution above and all works as it suppose to. However, I have another Workflow on my list that gets kicked off when a field is selected in my list. This Workflow then copies the item to another list, and deletes the item on the current list. The trouble is when this Workflow runs and does the copy and delete, it leaves my Counter Workflow in a "In Progress" state even though the item doesn't exist in the list anymore. All Workflows are done using SharePoint Designer. I have pulled my hair out on this one and just can't figure out what I'm doing wrong. Any help or insight would be grateful. Thanks for the article as well. Saved me some serious time figuring out what was going on post SP2 updates.

• Anonymous
  November 30, 2009
  Hi Stephen, Whenever there is an update in the List Item, A new workflow starts and the old workflow is already "In Progress" as it is in "Pause" state (appears as an old version of the workflow). Is there any way to stop that old version so that there are not more than one workflow is waiting to be executed?

• Anonymous
  December 04, 2009
  Stephen - Thanks.  Works great!

• Anonymous
  February 03, 2010
  I couldn't figure out why my workflow stopped working when it had worked fine a few months ago - then I found this article, thanks Stephen!

• Anonymous
  February 10, 2010
  Nice Post. But i need to implement an email 1 day before the due date. I can pause till Due date -1. But how do restart the workflow when Due date has changed. I need to recalculate the pause time again.

• Anonymous
  February 23, 2010
  Great atricle and this did the trick :)  I've set this up as described however, my counter isn't being incremented.  Since I can't post a picture, here's what I have configured for the "check status again" step: Set Variable: CurrentCount to Tasks:Counter The Calculate Variable: CurrentCount plus 1 (Output to Variable: NewCount) Then Update item in Tasks Any insight into this could be greatly appreciated.

• Anonymous
  March 17, 2010
  I have a list called ListA. There is a workflow that runs on listA everytime a new item is created or a list item is changed. The workflow creates a new task in the tasks list. The task list, let's say is called ListB. There is another workflow that is set to start when a task item is changed. The workflow on listB updates ListA with values collected from the task when the task is completed. Since the item on ListA has now been modified by Workflow on listB, it casues the workflow on ListA to trigger, thus causing  a loop. I wish there was a way I could make the workflow trigger when an item is edited rather that the when it is updated through a workflow. I think SP2 does not cover my issues or does it?

• Anonymous
  March 17, 2010
  Any solution for Kevin's question on 2/11/2010?  How do you reset the Pause time again when the Due Date is modified on the list? My testing doesn't reset the pause .  It waits until the original pause duration which is a problem.  If the user changes a date from somewhere in the future to a day closer than the original (example: original date: 3/25/10 changed to 3/18/10) the workflow waits until he original pause duration passes then the workflow starts again.  By this time, the task should have had multiple past due reminders but nothing will happen until 3/25/10.

• Anonymous
  March 18, 2010
  On the other hand, if I made it just one workflow that updates listA then the implentation of SP2 will resolve my problem. Thank you for the example.

• Anonymous
  April 09, 2010
  Do you know of any way to create this same looping affect when two Lists are involved? Example: List A is Training Courses, List B are all the students registered for all the courses. The two lists are linked by the Training Course number and the Training Course ID number. Can you create a loop effect that when data in List A changes, that it automatically updates all the linked records in List B? I use to be able to look this prior to SP2 and now can't...but need to.

• Anonymous
  April 10, 2010
  Hi I am using srvice pack 2  version 12.0.0.6421. I am triggering the workflow when an item(document) in a document library is added is updated. I need to update the Approval Status filed to Approved after the manager approves the document since I am updating the Approval Status field the workflow is entering into infinite loop. If I am updating any other custom column I am not entering into infinite loop. But I need to update the Approval Status field in order to hid the document from others (except creator and Approver)unless its approved. The document should be Approved even if its modified. So how to avoid this infinite loop Can anyone please help

• Anonymous
  April 19, 2010
  I am looping through a list of items from one list and creating items in another list. I have run into an apparent issue where I can only create what appears to be 8 items at a time? Is there a limitation on the number of list items that can be created as some way to cap infinite loop issues?

• Anonymous
  May 30, 2011
  Great explanation! Thanks. I am running into a slightly different problem that may be related. I have post it here (social.msdn.microsoft.com/.../4d55919c-5c61-447a-ac9e-20acfad96a5d) but the crux is that I cannot get a workflow to trigger from a newly created task/list item if the item is created by the “Create Item activity” in another workflow. Is this a problem or am I doing something wrong?

• Anonymous
  September 28, 2011
  Oh, thanks!  I was just looking for something like this.

• Anonymous
  October 12, 2011
  This is great!!!  It works like a charm and I adopted it with little modification to suit my needs.  I made a flowchart of it, perhaps you might be interested in looking into it; it gives the overall view. Again, thanks!.

• Anonymous
  October 25, 2011
  I am new to SharePoint. The above example is not workign for me. The second workflow is not starting when the item is changed. Do we need to configure anythign for this?

• Anonymous
  January 26, 2012
  Hi, will this approach working fine for sharepoint foundation 2010 ? any body used ? please let me know, because I tried this wonderfull approach in SP Foundation 2010, with pause duration of 5 minutes (For testing purpose, i kept like that. in real scenario the duration will be 1 day), The workflow will be sending only 3 emails, after that both the workflows are completed automatically. Thanks in advance Ganesh

• Anonymous
  February 13, 2012
  I am program manager of SPD and I tested this with SPD2010 and MOSS2010 without special configuration. I could see it work fine. I set it to 5 min duration and the 5 items I test with keep sending mails upto 13 and 8. (and it is ongoing without completion on both workflows.) The first workflow is started on creation of an item and then call the second workflow by updating the field, and then finishes. The second workflow sends the mail and call the first workflow by updating the field. And this goes forever until the item 'status' field is updated to Completed.

• Anonymous
  February 13, 2012
  Padam, would you make sure that you selected the start options correctly? For the second workflow, it should start on item update. For the first workflow, it should start on item creation and update.

• Anonymous
  July 24, 2012
  Thanks for the solution, but in my case the two workflows only loop about 10 or 11 times, and then they don't activate again when a field changes inside the workflow. It's the same than happen in this page: go4answers.webhost4life.com/.../sharepoint-designer-2010-workflows-not-23271.aspx Someone can help me? Thank you very much! Greetings.

• Anonymous
  September 26, 2012
  This solution is not working for me on Sharepoint 2007. The first workflow starts, then the second workflow starts and update the field in the list but this update doesn't trigger the first workflow and it doesn't start back. Any solution? Thanks in advance Conrad

• Anonymous
  November 05, 2012
  The comment has been removed