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

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.

VN:F [1.9.22_1171]
Rating: 9.2/10 (53 votes cast)

About Matt Milsark

At Fpweb.net, Matt builds many of our clients' environments as well as supports and maintains them. These range from a simple dedicated single server to large multi-server SharePoint farms. Because of the sheer number of clients we have and the myriad of ways they use SharePoint, Matt has become intimately familiar with many aspects of SharePoint. Matt warns, "SharePoint is a beast. You may think you’re an expert at SharePoint, only to find out later you’re an expert at merely a small aspect of the beast's capabilities." Matt is also passionate about vinyl records. Check out his music site at lplives.com.
This entry was posted in SharePoint Tips & Tricks and tagged , , , , , . Bookmark the permalink.

24 Responses to SharePoint Headache: Change in ‘Wait for Field Change’

  1. Paul says:

    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. Pingback: fastimplementation.zendesk.com

  3. Colin says:

    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 says:

    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 says:

    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 says:

    @Paul
    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: http://thesharepointhelper.blogspot.com/2015/04/sharepoint-designer-2013-action-wait.html

  7. Dan says:

    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 says:

    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 says:

    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 says:

    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 says:

    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 says:

    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 says:

    @Paul
    The loop function works really well!

  14. Wouter Lusink says:

    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 says:

    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 says:

    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 says:

    @Remco
    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 says:

    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 says:

    @Paul

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

  20. Yaniv says:

    @Paul
    Thanks Paul.Your useful comment saved me..

  21. Catherine says:

    @Paul

    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?

  22. Yazan says:

    Lovely workaround, I was surprised when I found that “changing the operator” piece was gone! and although Microsoft might have an explanation for this, but I can’t think of any logical one! “WHY” on earth would you guys remove such a nice feature :(
    Great post, thanks for sharing this.

Leave a Reply

Your email address will not be published. Required fields are marked *

Let's make sure you're human first: *