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.