On a recent client project, we’re working to implement a task-based tracking solution in SharePoint 2010.  The initial iterations dealt with creating a set of tasks using a SharePoint workflow that called a PowerShell script.  There is a parent Project, and that Project has a template set of tasks the workflow creates with due dates.  Then the requirement came up where if the Project due date changed, all of the task due dates needed to be updated to. 

I know what you’re thinking, Microsoft Project does this!  It has this cascade task update built-in, but we are using SharePoint. 

Normally, you would have three options:

1. You say “When a SharePoint workflow is triggered on item update, it can’t tell which field changed because it’s fired after the change has already been saved”.  You would be right.
2. You leave the workflow running, and you use the workflow action “Wait for field to change”.  This isn’t always advisable due to performance but could certainly work. 
3. You write a custom event receiver that will do exactly what you want.  It fires before the change is registered and can tell what the old and new values are (called before and after properties).  But this is messy and it takes code and stuff.  I’m not a developer. 

There is a 4th option and the path I chose to solve this issue, and it actually turned out to be fairly simple.

The Solution

This way involves the use of a hidden secondary field to hold the old value of the field, and then we can use that to compare to the new value of the field.  I do not claim to be the first one to think of this but I haven’t seen it documented. 

Here’s how this works.  We have a Projects list, and it has a Due Date list column (type date/time).  We add another list column called Old Due Date (type date/time) to store the old value from Due Date.  This Old Due Date column is hidden (via the content type) so no users will see it. 

How do we use this?  This is how the flow will go:

1. The user creates a list item filling in a value for Due Date. 
2. Workflow firing on item create sets Old Due Date from Due Date.
3. The user updates the list item and changes the Due Date value.
4. Workflow firing on item update compares the dates in Due Date and Old Due Date.
   1. If they’re the same, just stop the workflow as no change needed
   2. If they are different, we’re good to go and  need to update our task due dates.  We also go ahead and copy the new Due Date to Old Due Date so we’re ready for the next change. 

I added another checkbox called Bulk Update Tasks? column in case the user wanted to update the Project Due Date but not affect the child tasks. 

I know what you’re thinking, that was too easy!  Here’s what the workflow looks like in case you were wondering of the details:

While I won’t get into writing workflow, you still have time to sign up for our SharePoint 2013 Power User training class happening on April 4th 2017!  You can click here to check up on all our upcoming events. 

If you have any questions on workflow or anything else SharePoint, reach out to us!