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.


· 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.


Comments (39)
  1. Josh says:

    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;

  2. Hello Stephen,

    First of all thank you so much for sharing this information with the community. I have no doubt it will save many people hours of frustration trying to understand what has been changed with a relatively easy to implement (and well articulated) solution.

    However I was wondering if you could provide a bit more information as to why this change was made. I know a considerable number of businesses and business users impacted by this change and while over time they can resolve it, it would be really nice to have more explanation for the motivation behind a change of this magnitude.

    The initial reason described sounds more like a training, logic, and user issue instead of a technology one. However this might be me misinterpreting the message.

    My concern is: In most scenarios complicating the process increases training, decreases user adoption, and makes the entire situation more difficult to manage, so it would really help/be appreciated to have more ‘business’ or ‘technical’ reasoning behind why this change was made/is so important. (Otherwise it might be hard to convince many businesses to switch to SP2 – if business users have to re-work/re-do many of their existing workflows made in SPDesigner).

    Thank you in advance for any response,

    Richard Harbridge

  3. trockwell says:

    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?  

  4. Josephine says:

    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?



  5. Eilene Hao says:

    Re: Richard’s questions about the motivation behind the change: Workflows that do not automatically restart itself is actually one of our most frequently requested fixes and top support issues, for both functionality and server health.  The infinite loop prevents the ability to create common, simple workflows that modify status or change fields on the item in its completion cycle.  Infinite loops that are not designed to terminate are actually harmful to the system (e.g. the flooding inboxes, or an infinite loop that creates items indefinitely; all will eat system resources to run), and a lot of people create these infinite loops without realizing it, because they think of a change to the item as just part of the logic inside the running instance, not something that will cause it to run again and again.  

    So the fix is really there to make simple, most common case work as expected and prevent inadvertent infinite loops that are unintentionally harmful.  You could think of the ability to create infinite loops in a single workflow as a bug or "loop" hole;) that you could leverage to work around not being able to insert loops directly in SPD (note: the accidental attacks are also why SPD doesn’t have looping to begin with).  We knew there would undoubtely be power users who would have intentional loops designed to terminate correctly, so we made sure the fix would provide a workaround the correction by doing what this describes to get around it.

    I hope this helps clarify why this is in place.

    re: trockwell’s question, this does not impact item creation or modifying items outside of the workflow. It’s only impacted when the workflow itself updates the item.

    re: Josephine’s question: there is no column level acls as far as I know, but you can create separate views for different people and potentially send them notifications with different links to the views that are appropriate for them.

  6. Marcia says:


    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?


  7. RaokChandra says:

    Can I consolidate all the tasks and send one email, instead of sending one email to each task?  How can I achieve this?



  8. Paul Smith says:

    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?

  9. Isaac Abrego says:


    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

  10. cristina says:

    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]


  11. Christy says:

    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])



  12. Joe says:

    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?

  13. Yorick Kuijs says:

    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?



  14. Yorick Kuijs says:

    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.

  15. Stephen says:


    Have a look at this earlier post from Darren on "Workflows and user context":

    See esp. this paragraph — do you need to do this on your server?

    "In the SharePoint Infrastructure public update box administrators can allow email enabled lists to trigger workflows as the last person to save the workflow when an item is created via email.  Run “stsadm.exe –o setproperty –propertyname declarativeworkflowautostartonemailenabled –propertyvalue yes” on the patched server to enable this."


  16. Samer says:

    Great idea! A lot of fun to do with it 🙂

    But is there a similar trick to loop for each in a usermulti?

  17. Ray says:

    Hi, I believe my environment has SP2 installed already, yet I’m still seeing the infinite loop problem with the simple out-of-the-box approval workflow. The workflow is associated with a document library. I have the following settings enabled:

    Start this workflow when a new item is created.

    Start this workflow when an item is changed.

    When a new document is added, the workflow creates a new Task in the Tasks list, which is assigned to a SharePoint group. When one of the users in that group approves the workflow Task, however, the workflow creates a new Task pending approval by the same group. This process repeats itself indefinitely.

    After I uncheck the "Start this workflow when an item is changed" setting, the infinite loop stops. And the approval flow works as expected.

    I checked the server everywhere, and it seems that Service Pack 2 for Office SharePoint Server 2007 and Windows SharePoint Services 3.0 has been installed. The version number of MOSS 2007 is 12.0.6425.1000.

    Yet this contradicts what the original post said. What’s going on?

  18. inkspot says:

    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.

  19. Mahen says:

    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?

  20. Chad says:

    Stephen – Thanks.  Works great!

  21. nick says:

    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!

  22. Kevin says:

    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.

  23. Greg says:

    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.

  24. Aamir says:

    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?

  25. Kerrie says:

    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.

  26. Aamir says:

    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.

  27. Linda says:

    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.

  28. kiran says:


    I am using srvice pack 2  version

    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

  29. Eric says:

    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?

  30. Patrick says:

    Great explanation! Thanks. I am running into a slightly different problem that may be related. I have post it here (…/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?

  31. Robb says:

    Oh, thanks!  I was just looking for something like this.

  32. Steve says:

    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!.

  33. Padam says:

    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?

  34. Ganesh Thirunavukkarasu says:


    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


  35. JongHwa Lim says:

    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.

  36. JongHwa Lim says:

    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.

  37. Anulot says:

    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:…/sharepoint-designer-2010-workflows-not-23271.aspx

    Someone can help me?

    Thank you very much!


  38. conrad says:

    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


  39. Thank you so much for posting, I have been banging my head against the wall for weeks now. After reading your post, I was quickly able to implement the solution I was looking for. Thanks again.


Comments are closed.

Skip to main content