SharePoint Headache: Change in ‘Wait for Field Change’

With every new version of SharePoint, there are expected changes.

Some changes are minor, some are major; some you’ll never notice, and some are just frustratingly trivial. So, what do I mean by frustratingly trivial? These are changes that, at first glance, seem minor and inconsequential, but in truth lead to many headaches and a yawlping “WHY?!”

There were quite a few changes in SharePoint Designer 2013 regarding workflows: The concept of stages was added, Microsoft finally gave us an easy way to loop actions, and now it’s really easy to assign tasks and call a web service. These are all welcomed changes (for the most part).

One change, however, is not welcomed. And it definitely falls into the category of frustratingly trivial. The change is in the action Wait for Field Change in Current Item. It’s a great action, and one I use quite frequently.

In a previous blog, I talked about creating an approval process on the form. This was a critical action. It still is a critical action, but it was much easier to implement in 2010. Here’s why: It provided you a trigger to continue the workflow based off a number of options. Here’s the action in 2010. You can specify the field, the operator, and the value.

Wait Action in SharePoint 2010

Wait Action in SharePoint 2010

What do I mean by changing the operator? Click on the to equal, and you are presented with the following options:

Operators in SharePoint 2010

Operators in SharePoint 2010

Now, here’s the same action in the SharePoint Designer 2013.

Wait Action in SharePoint 2013

Wait Action in SharePoint 2013

Notice now you can only change the field and the value. And the value has to be equal to. There is no other option. If you want the workflow to continue, the value of that field must equal something.

This may seem like a minor change, but let me tell why it was a headache for me.

In 2010, it was easy to stop a workflow and await a response in a specified field. It could be any response. Consider the following example:

In my requisition form there is an Approved field. This is the field where the manager either approves or rejects the request. So the workflow goes like this on every new request created:

1. Send email to manager

2. Wait for manager to respond

3. If manager rejects request, stop workflow

4. If manager accepts request, continue to procurement

5. If manager needs request modified, send back to employee with manager notes

In SharePoint 2010, the action immediately following the email to the manager would be a Wait for step. It would say simply:

then Wait for Approved to be not empty.

Nested if thens would take care of the rest (if Approved = accepted go to A; if Approved = rejected go to B; if Approved = Require Modification go to C).

This is linear and logical. It’s easy to configure and easy to understand.

Now, in SharePoint 2013, it’s simply impossible to create a linear workflow that accomplishes the similar task because you do not have the option to specify the operator in the Wait for step. You can only specify a value the field needs to match. So, you can’t do:

then Wait for Approved to equal Approved

Because if the item is rejected, the workflow never continues.


Why was this removed? It seems such a little change, but it adds unnecessary complexity to an otherwise easy to configure workflow.

So how do you get around this SharePoint headache?

My solution was to use parallel blocks.

Honestly, I’m not convinced this is the most efficient way. It certainly seems less efficient than how the solution was implemented in 2010. But I couldn’t find another way without having to write custom code. And it works well.

Basically, I created a Wait for Approval Stage and used parallel blocks to wait for the item to change.

Parallel Blocks in SharePoint 2013

Parallel Blocks in SharePoint 2013

As you can see in the screenshot, there are two parallel steps (displayed here). One step waits for Approved field to equal Approved; the other waits for Approved to equal Rejected. If the item is approved, the workflow continues from the Approved stage. Similarly, if rejected, the workflow continues from the Rejected stage.

Like I said this solution worked in this scenario. But I still ask, “Why?”

Why did Microsoft change the options for the Wait for action? In this SharePoint administrator’s humble opinion, it has resulted only in frustration and extra steps.

2014-06-05T08:38:13+00:00 June 5th, 2014|


  1. Paul July 9, 2014 at 3:09 am - Reply

    Great article. I have been trying to find a workaround for this issue for a while and agree with all of your frustrations.

    There is one step missing from your instructions though. By default a parallel block will wait for ALL actions to complete before it moves on. This was a stumbling block that I had run into before. However, if you right click on the block and choose “advanced properties” you can tell it to continue if a Boolean workflow variable becomes true. So for my workflow I for either approved or rejected I set a variable I called ApprovalStatusFinished to true which allows the workflow to continue without waiting for the other parallel step to also complete.

  2. July 11, 2014 at 2:56 am - Reply

    SharePoint Headache: Change in ‘Wait for Field Change’

  3. Colin December 16, 2014 at 3:06 pm - Reply

    Hi, Thanks for the information. Can you recommend a solution were I need to “Wait” until a date is not equal to another. I cant see a way to use your method to get around this.

  4. joão antunes December 26, 2014 at 11:57 am - Reply

    it’s because they want to give space for third-party expensive plugins to do the same. just like visual studio. it sucks on purpose, se we have to buy ReSharper and other stuff so it can have features all other IDEs have from day one.

  5. Jeff April 21, 2015 at 9:28 am - Reply

    I having the exact same problem. I think there might be an error in your article, it says “the workflow continues from the Approved stage. Similarly, if rejected, the workflow continues from the Rejected stage.” I think you meant “step” instead of “Stage”. How hard would it me to write a custom action to create the same action that 2010 used?

  6. Jeff April 21, 2015 at 10:08 am - Reply

    Paul you are right, without the Boolean workflow variable, the above example will not work. I have published a screenshot of the workflow with the Boolean variable here:

    • Steve January 3, 2017 at 7:53 am - Reply

      Wow, I’d like to see this but your blog is only open to invited visitors. Thanks!

  7. Dan June 7, 2015 at 6:00 pm - Reply

    I came up with another, equally complicated workaround for this. In my case, I need to wait for a text field (Title, which is hidden in the NewForm and is generated by a separate workflow by concatenating several other columns’ values) to not be empty, and it could contain any value – I’ll be inserting its value into some text later, rather than making a decision from a small number of possible values.

    I used the new looping command to loop “while Current Item:Title is empty” -> Pause for 0.1 minutes (initially, you can only use integers in the pause duration, but then advanced properties lets you input 0.1). But I suspect this might cause something of a performance impact to the farm if several instances are looping in this way.

  8. Fabio Brandão July 28, 2015 at 2:20 pm - Reply

    I’m really frustrated too.

    I started to put a parallel action and for each answer a different step. But to maintain the same logic with 2010, I put in parallel a waiting for every possible answer and put an variable with true to finish other parallel actions.
    Then all ifs and elses to take the desired actions.

  9. Michele July 28, 2015 at 8:40 pm - Reply

    You could use InfoPath to add a field to your form, eg FormStatus, and create a rule that runs when the Approval field is changed to set FormStatus to a specific value, eg Responded. Your workflow could then use Wait for FormStatus to equal Responded.

  10. Curtis Robinson July 30, 2015 at 12:10 pm - Reply

    I completely agree, SharePoint designer 2013 workflow is an exercise in frustration.
    Another issue is the action to change workflow status to Canceled? I often used it to stop a workflow on a condition. It no longer works in 2013 and there appears to be no alternative as the “go to stage” action didn’t make it into the production workflow release either. So how are you supposed to stop a workflow based on condition logic?
    Microsoft, why bother with this crippled workflow version?

  11. Paul Mare August 28, 2015 at 10:55 am - Reply

    You could also do this:

    Set field “Waiting” = Yes
    Generate a Task or something else
    Wait until Waiting = No

    and set the field Waiting form the Task / InfoPath form etc.

  12. Jerry Cote September 8, 2015 at 6:34 am - Reply

    Why? Because SharePoint! Need there be any other explanation?

    It was likely something the dev team just forgot to do. When you’re rewriting a whole code base from scratch as they likely did, you either spec out everything in detail, or you don’t, and stuff gets lost. Not that they haven’t had ample time to make it up – but that costs, and the MARKETING team needs that money!

  13. Colin October 22, 2015 at 10:29 am - Reply

    The loop function works really well!

  14. Wouter Lusink December 23, 2015 at 1:32 pm - Reply

    Hi, in my case I had an int32 field which was 0. The workflow had to continue only when the field had a value in it other than 0.

    I solved this in the following manner:

    first I created a variable currentValue of type int32.
    then I created a While loop with condition currentValue == 0

    In the While body, I did a WaitForItemEvent. Current List, Current Item, “When an item is updated”. The output I put in a dummy variable.

    Right after this Wait step, I do a LookupListItem and I get the value of the int field into currentValue.

    That’s it!

    The while loop will only start again if the int field is still 0 (This will be the case if another field was updated).
    The WaitForItemEvent will make sure that I’m not polling.

  15. dbaranyi January 12, 2016 at 4:24 am - Reply

    there is another option:

    – turn on versioning for the list
    – in the workflow, get the item’s version number and store it in a variable
    – increment it by 1
    – wait until the item’s version number equals this incremented value (which means the item has been modified)

    This way you don’t have to use any loops or the WaitForItemEvent action which executes when ANY item in the list has been updated.

  16. Remco January 19, 2016 at 4:02 am - Reply

    I ran into the same issue. Solved it by setting a calculated field in SharePoint to a specific value when another field was not empty

    Used wait for [CalculateField] to equal [specific value]

  17. Cheri Bell February 9, 2016 at 3:11 pm - Reply

    Does anyone have a workaround for the “Assigned To” field? I am creating in SPD 2013 and would like to wait for the Assigned To field to be Empty. There is no way to create a calculated Field using Assigned To. Any ideas? This is a lot of work and time to do something in SPD 2013 that was easily accomplished in SPD 2010. Thanks!

  18. Steve February 13, 2016 at 3:05 pm - Reply

    The design of this function from Nintex is very poor. As a workaround, I compare the field to the same field (ex. Department field in Employee list to Department field in Employee list). It will always pass when the field is updated but then I test the value and continue to loop if it isn’t what I’m looking for. The bigger problem is when I want to wait on a change to a Site Column. Nintex only allows you to compare to a Lookup ID but it is pulling the actual field value to do the comparison. The design simply doesn’t work. I had to use the waiting on event function instead.

  19. Jigs March 16, 2016 at 5:26 am - Reply


    Thank you very much for this Advanced Properties Information. It worked.

  20. Yaniv August 24, 2016 at 1:26 am - Reply

    Thanks Paul.Your useful comment saved me..

  21. edsf February 17, 2017 at 3:33 am - Reply


  22. Catherine March 6, 2017 at 1:12 pm - Reply


    Thanks for your article. I have followed the steps you commented and it seems the Boolean workflow variable does work with the parallel actions, but once it reaches the end of the step, it stops and doesn’t proceed or transition to the next step of the workflow. Any idea what may be causing this?

Leave A Comment