Back in October I did an overview of the different ways to wait for a change in a SharePoint Workflow. You also have the option to wait for a certain time, there are two options which are waiting for a set duration or waiting until a set date. Either of which are easy to control or set. I am not focusing on these actions in this post, but just a quick note if you want the date to be dynamic when using wait until a date, then you will have to set the date you want in a workflow variable prior to setting the wait value. Otherwise your date is going to have to be static and that’s probably not going to work for you in 99% of your workflows.
Today, however I want to discuss waiting for a value to change on the list your workflow is attached to.
Bit of a disclaimer: Why am I still talking about SharePoint Designer? Why not Microsoft Flow? Don’t worry, I have some Flow blogs planned. However, Designer is still widely used and will be for some time. I encourage others to use flow where they can, but remember that not everyone has access to that yet. Designer is free and anyone with a SharePoint environment can make use of it. Hence, I still see providing insight and knowledge on this product very important.
I have a bit of a TLDR here as you may be just looking for the answer, and not WHY it is occurring. I strongly urge you to read the whole post to understand why things are the way they are and to make you a better person ;-p, but if you are in a hurry or think I talk\write too much, just click here to find out what you need to do.
What You Shouldn’t Do and Why.
I am not going to go too much into details of the two methods available to you as I covered that back in October. You can review that information here. However, I want to discuss with you why one of the methods, while seeming logical, is actually a bad idea. Remember in that other post how I discussed that you can’t wait for a value to change FROM a particular value you can only wait for a field to change TO a particular value? Back in SP Designer 2010 if you had a choice field and if you wanted your workflow to wait until the value changed you could just wait until the field no longer equalled the default on the list. For example, waiting for a status field to change from Received to Approved or Rejected. Then the workflow would wake up and complete its tasks based on the value the field now equalled. However, this isn’t an option now. You can’t change that setting in a 2013 workflow. So what is the best solution? Let me start off with one that is logical, but is actually a bad way to do it.
Most people used Wait for Event in List Item. This means you can wait for an item to be edited and then check the value of the field you need to check. If that value hasn’t changed, just loop back to a waiting stage until the item is edited again. What could go wrong? Well a lot of things actually.
Here’s what isn’t immediately obvious. It doesn’t wait for a value in the list item for which the workflow is associated with to to change, it will fire when any item in the entire list is modified. Doesn’t seem to bad right? Well what if you have a very active list? A lot of active workflows checking things can slow the system to a crawl and in some worst cases even cause save conflicts with users. It also affects your Workflow Manager as well. Here’s what I mean. Say you have a list with a couple thousand rows and at any time there are about 100 active workflows going on that list. Whenever any of those thousands of items get modified, each and every one of those active workflows is going to fire up and check to see if it was their list item that was modified and if not, then will go back to sleep. Pretty simple, except these checks if done in the hundreds take time and if it’s an active list, it will be almost constant because another list item will be updated and start the process all over again.
So I mentioned before that this affects your Workflow Manager. It does in that if you have hundreds of workflows queued up to be checked then any other workflows running in the farm that are going to be held up. The workflow manager can only handle so many items at once. So if there is 150 workflows to check because a list item was changed, than that workflow that was freshly started in another site entirely that is sitting at 151 in the queue is going to have to wait. For workflows that are time sensitive, this is not a good thing.
The other major issue I have come across over the years is around the Service Bus the manager uses. The service bus will, besides handing the messages happening between systems, also track the messages that were not picked up by the workflow manager. These are called deferred messages. In a perfect world these deferred messages are meant to be picked up again and utilised when the system goes looking for them or is ready to deal with them. This doesn’t seem to be the case in a SharePoint workflow. Workflow Manager CU 3 is supposed to address this. Normally you want your deferred message table to be below 10000 rows. This is because when SharePoint queries the workflow manager, the deferred message queue is checked and the larger it is the slower everything gets. In one situation I worked on with Microsoft we had a deferred message table of not 10000 rows, or 100 000 rows, but over 850 000 rows. It was taking workflows over 10 minutes to respond in some cases. Working with Microsoft we tried to fix it, but in the end actually had to build an entirely new instance of the workflow manager and remove the old one. This is why I am strongly against using “Wait for Event in List Item”
Best Practices: Waiting for Value Change in SharePoint Designer Workflow
Ok, so let’s get to what you all really came here to find out. What should you do if you have a field that you need to check for different values, not just a particular value. You need to use a Parallel Block. As its name implies, a Parallel Block allows any step within to run at the same time. It won’t do them one after the other, but all together. Because of this, we can do a check for each and every value inside the choice field. Because they each fire together this allows the workflow to wake up when the field you are watching changes within the list item. No longer will the workflow fire when any item is updated, nor will you have to worry about hundreds of workflows waking up constantly and running for no reason. I’ll illustrate how to do this below.
I have a very simple list that has a field called Document Status. This field is set to In Progress when the workflow starts and the workflow needs to wait until the status is updated. Had this been a 2010 workflow I would have set the workflow to continue when the field is NO LONGER set to In Progress, but since we can’t do that in 2013, we’ll use a parallel block.
The first thing you need to do is create a new workflow variable of type Boolean. This is because you need a way to exit the parallel block. A parallel block doesn’t require this, but because we don’t want the workflow to continue on without our fields being checked we need to set it.
So create a boolean variable, similar to the following and set the value to No:
Next create a Parallel Block. You’ll find that option in the Insert section of the Ribbon:
Next, right-click on the parallel block and select Advanced Properties
You will be prompted to select the value the Parallel Block needs to monitor. It will only exit the block when that value is true, which is why we had to set it to false before the block is created. When the prompt comes up, you can select the boolean you created.
Next within the block create a step for each of the values in your choice field you want to check for:
Then within each step, add your waiting action:
Now even if your value changes, if you don’t tell the parallel block to exit, your workflow won’t continue. So update the boolean you created earlier:
This will now allow you to check the values of a particular field even if there are more than one possible outcome to check for. Once you have this complete you simply need to complete your branching and workflow as you need.
This method isn’t perfect. If you have a lot of options for users to select, it’s going to take some time and make for a long section to add, but in the end you are going to get a much better result overall then using the Wait for Event in List Item action.
Thanks for Reading!
Never thought of using a parallel block to solve this – Brilliant !