Task vs. Email vs. Task

Email is probably the most popular entry in the array of services that we provide to our employees, but it’s a poor substitute for mom. Email can be ignored and email can be forgotten. Your email client might remind you of appointments scheduled in your calendar, it might remind you of tasks that you set-up with a deadline, but the stuff in your inbox? That stuff is allowed to pile up like laundry. That is why I like SharePoint task lists. SharePoint can be mom-like in the way it reminds you that a task will be due soon, and it can be positively mom-like in the way it hounds you after that deadline has passed.
The problem with task lists in SharePoint is administration. Unless you have a Type-A project administrator, creating tasks for team members is tedious, time consuming and, if they aren’t created properly, the task is little more than a nag-note. Plus, even when the task is completed, there is still one more thing to do, go back to the task list and set the status to ‘Complete’ (and for the truly anal managers, set the completion percent to 100). We wanted to avoid these drawbacks to tasks in our recent SharePoint project, but we missed the bull’s-eye by at least one ring.
As the engineering inspection reports we have been dealing with are created (or uploaded) and edited, they move through various stages where the next step belongs to another person. We decided to automate this using SharePoint Designer workflows. Here is a short list of the cool things we took care of:
1.   Status – We base the creation of tasks on the status of the inspection, or the documents that are part of the inspection set.  That means things happen when they should happen.
2.   Processing – We keep track of the processing that has already taken place; if a report is edited, but the status remains the same, we don’t create duplicate tasks.
3.   Group Notification – We assign the tasks to groups rather than individuals when the process to be completed can be performed by multiple people.
4.   Re-Processing – We are providing for reports to ply the edit-review cycle more than once.
5.   Optional Review – We use a related SharePoint list to lookup the facility being inspected and determine if a peer-review is called for.
6.   Clean-up – After the status indicates that a task has been completed, the workflows delete the task entry, or set the status to ‘Complete’. This way, SharePoint stops hounding without anyone ever having to edit the task one last time. An additional benefit of this step is the fact that the task list never includes anything but active tasks.
Pretty impressive; at least we thought so. OK, what did we leave out? SharePoint tasks generate an email to the person/group that the task is assigned to, but in the true spirit of self-importance, the link in the email is to the task. If the person is being assigned the task of reviewing a document, we need to have the email include a link to the document.
As soon as we realized this oversight, our first thought was “why don’t we just send an email from within the workflow?” That would seem to solve the problem and simplify the process. Then again, sending the email robs us of the mom factor. Sending an email is simply not a trustworthy notification mechanism these days – we get too many emails to take them all as seriously as we should. Once in my inbox, that email slips further and further toward being irrelevant with every passing hour. SharePoint, on the other hand will wait only so long before it fires off another reminder. The other problem with using email notification surfaces when group notification is required. If four people are notified via email that a document has to be reviewed, it becomes their responsibility to notify each other when the review is complete. Using the task list solves that problem; everyone in the group gets notified when the task is assigned. When the document changes are made, the workflow sets the task as being completed, and everyone in the group is notified at that point as well.