Sometimes you need to have a workflow that loops through all the items in a list and then matches them on some criteria and performs an action. Considering the following all-to-often occurring scenario…
You setup a list of tasks, or some sort of tracking list and assigned tasks go uncompleted because people don’t mark them as complete. This will happen to you if you use SharePoint. Death, taxes and incomplete SharePoint tasks are 3 things that are unavoidable in life.
You need a way to remind them that they have an open task assigned to them.
The problem is that SharePoint does not support a workflow that runs against the entire list. Workflows run against a single item. Whichever item initiated them.
The key to solving this without cracking open Visual Studio is to resign yourself to working with a single object at a time. Instead of a workflow that runs AGAINST all list objects, we are going to create a workflow (2 actually) that runs FOR each list object.
The idea here is recursion. Recursion is a programming principle that simply means a function or method that calls itself. Simple. What we need is a workflow that calls itself. The workflow should just run non-stop until a condition is satisfied and then an action is taken.
This is not possible anymore as of SP 2 – which is a good thing because you don’t always want endless looping in your workflow. As of SP 2, a workflow can no longer initiate itself.
We can get the same effect using 2 workflows. Here is the logic..
- We have a field in our list item that the user never sees called “BeingProcessed”. It’s a Yes/No field that defaults to “No”.
- We have 1 workflow that initiates manually, on create and on change.
- We have a second workflow that initiates only on change
Here is the kicker – both workflows are going to do EXACTLY the same thing. Here is the workflow logic in psuedo code…
if the BeingProcessed field of the current item is “No” and our other condition is satisified (for instance, the modified date is 2 days old and the task is still open), we are going to set the BeingProcessed flag to Yes, send an email to the assignee asking them to please close the task, and then we are going to set the BeingProcessed back to No.
else if the BeingProcess field is “No” and our other condition is not satisified, we are simply going to set the BeingProcessed field to “Yes” and then sleep for a certain amount of time (lets say 24 hours). After that, we are going to set the BeingProcessed back to “No”.
What does this do?
It causes 1 workflow to either take an action or sleep for 24 hours and then wakeup and change the item which causes the SECOND workflow to kick off and do exactly the same thing, initiating the first workflow after it completes by also updating the item. What we then get is a single workflow that is running ALL the time on a given item until certain conditions are met. It seems heavy handed, but all we are doing is a quick check and then going to sleep for 24 hours. It’s very light when you think about it.
That’s an easy way to do “looping” without writing a single line of custom code. ALL of that can be done in SharePoint Designer.