A short guide on how to create SharePoint checklists
I’ve come across the requirement to have checklists available in SharePoint quite often. But somehow I’ve always managed to get out in time before the requirement moved from the project’s short list into its product backlog. Till now. Googling for inspiration it seems that opinions differ on how to best translate the concept of a checklist into the SharePoint world. Some blog posts mention using a SharePoint Survey. I personally don’t believe in that approach. SharePoint’s Survey can hardly be customized as it’s very much a locked-down application in itself. And a SharePoint checklist app will need at least a bit of customization. You probably want to assign individual checklist items to different people. You also may want to set different due dates for individual checklist items. To me it seems that a checklist is best mapped to SharePoint in the form of a collection of tasks. Such a virtual collection can easily be created using views that group tasks for example by a Checklist ID.
A more complex challenge that needs to be tackled is the fact that a checklist is a copy of the orginal source checklist. Think, for example, of a New Hire Checklist with a couple of tasks on it: IT needs to provide a network logon and email address, facility is requested to create a new access badge … Well, I guess you get the picture. Most likely the New Hire Checklist is “owned” by the Office Manager. Each time a new employee starts working with the company, the Office Manager will print out the New Hire Checklist two weeks in advance. He or she then sends copies of it to the people involved. Maybe you’ve received one of those in the past; attached as a Word document to an email. It’s an fairly easy and quick way to ensure that people complete tasks assigned to them in a consistent manner. In fact, if you’d have to manually create and assign new tasks in SharePoint over and over again: it seems more effort instead of less. I consider finding a easy-to-use and time-saving way to overcome this challenge the key to a successful SharePoint checklist solution.
So let us think … You can create two task lists. In the first list you would then manage individual tasks, each one in fact representing a checklist item. Let’s call this list simply Checklist. It’s a custom list that will hold content of a custom type Checklist Task .
This is simply a new custom SharePoint ContentType that inherits from the SharePoint Task ContentType with only one minor modification: an additional (site) column to register the Checklist ID (a number, starting at 1). The second list is identical to the first list. However, it will hold copies of the tasks that make up the checklist. Let’s call this list Assigned Tasks .
You can also think of the Checklist list as a collection of prototype tasks. It is the actual source of our checklist; the orginal document that lies somewhere on a shared network drive and that is used by the Office Manager time and again to create new copies. If you want to change the checklist e.g. by adding a new task, changing or deleting an existing task, then you would apply your changes to tasks in this very list. You could basically stop here. You can use the datasheet view to bulk copy selected checklist tasks from the source Checklist into the Assigned Tasks checklist. You maybe want to manually update the Checklist ID field so that you’re able to aggregate tasks into a checklist view.
But you can also try and automate this step of creating a new checklist based on the source checklist by creating a re-usable workflow using SharePoint Designer and the out-of-the-box workflow actions and conditions. This workflow should be able to be started manually. For each item in the Checklist list, it will then create a new item in the Assigned Task list. However, this is easier said then done. Why? Because SharePoint Designer Workflows don’t support for-each loops or any other form of itterative processing. In other words: You cannot itterate through all items in the source list. However, we can create two workflows that keep each other going until the last item has been processed before the last workflow will run into an error (because it cannot execute succesfully as there are no more list items left). I’m not saying that this is an ideal solution, but having tested it I can say that at the very least it works nicely and solves the SharePoint checklists challenge in a highly automated fashion using only out-of-the-box tools; no custom development is needed.
You can see from the screenshot above that I’ve created two workflows. The first one is called Assign Checklist Task and is associated with the Checklist list. It can be started manually but will also start automatically when an item in the list is changed (see screenshot below).
The second workflow is called Invoke Next Checklist Task Assignment and is associated with the Assigned Task list. It will start automatically each time a new item is created in the list.
The first workflow basically executes as follows:
- Check whether it was manually started for the first item in the Checklist list
- If this is the case then a variable will hold the next Checklist ID (current Checklist ID + 1)
- Otherwise it will assign the Checklist ID value of the current item (you’ll see in a bit that this will be updated by the second workflow)
- Then create a new item in the Assigned Tasks list whilst copying values from the Checklist task
- Creating a new item in the Assigned Tasks list will invoke the second workflow
- And finally set the Checklist ID value of the current item it’s processing (setting a value instead of updating a value prevents the workflow from running again)
The second workflow executes as follows:
- Calculate the previous Checklist ID (as the current Checklist ID minus one)
- Then update the first item found in the Checklist list that hasn’t been processed (because its Checklist ID hasn’t been set to the current Checklist ID)
- Updating the Checklist list in turn invokes the first workflow again
- When no item is being found in the Checklist list, this workflow will simply die gracefully, only reporting that an error occurred
As a result the Assigned Tasks list will now hold new tasks that can be easily identified by the latest Checklist ID.
Of course this is still a very minimalistic solution and will need some documentation and instruction on some do’s and don’ts. For example, you should always select the first task in the Checklist list when you start the initial workflow to create a new checklist (instead of a random one). Also you should temporarily disable the workflow associated with the Checklist list when changing tasks. On the other hand, this way you’re really flexible in handling, manageing and tracking tasks and checklists. And it’s easy to extend this simple example with more complex checklist scenarios e.g. by creating branches since it was built using only out-of-the-box SharePoint artifacts.