A recent client wanted to see if there was a quick way to provide a set of common tasks for new employees joining the organization. Each new employee joining the company has a list of tasks they should complete to be properly oriented with the organization. In the current process, HR provides a recommended checklist to the employee and reviews key policies, but they have no way to know if the employee has completed the recommended checklist or to hold managers accountable for reviewing policies and procedures required of the new hire.
The client came to us hoping we could provide a simple solution to help. They already use SharePoint heavily and desired to see SharePoint help them track new hires and orientation. This was a perfect test for Nintex Workflow 2010, and hopefully this will showcase some of the potential workflow solutions that you might be able to provide using this 3rd party tool.
Before digging into this solution, take a moment to check out the Nintex website. Nintex Workflow 2010 is a 3rd party tool that is installed on the SharePoint server. It provides some very complex interactions that extend SharePoint in some pretty impressive ways. The workflows are designed entirely using the web browser and can be exported and reapplied to new lists very quickly.
First, here is an introduction to the Nintex Workflow 2010 designer. The designer integrates directly into SharePoint 2010 and doesn’t feel like it is a separate product. When designing workflows, the ribbon reflects commands related to workflow design. On the left hand side is a list of available workflow actions. They are broken into major divisions and then can be simply dragged from the actions panel into the designer.
Each workflow action has it’s own set of configuration options, all done through the browser. If an action is missing some key information, it will be highlighted with a yellow exclamation point. This makes it easy to determine where information may be missing. Additionally, each action supports four different labels to help the workflow designer better describe why the action is on the design surface.
The solution we proposed consists of three lists: 1) New Hires, 2) New Hire Task Templates and 3) Tasks. HR is responsible for creating the common tasks each employee needs to complete for a successful orientation. The data entry needed to remain simple and allow modification as the business evolves.
When the organization has a new hire, the information for the new hire is entered into the New Hires list. After the new hire information is submitted, HR wants the tasks to be created for the new hire and a notification to be sent with a URL for them to review their outstanding tasks.
To keep the solution simple and to demonstrate the major functionality, I will only highlight the necessary columns for the solution. Of course, in the final solution there are more columns and conditions to determine which tasks will be created for each new hire. Following are the major columns needed for each list:
- New Hires
- Employee (Person or Group)
- Start Date
- New Hire Task Templates
- Days to Complete : Number
- Task Description : Multi-line Text
The New Hires list captures the employee name and the starting date. The starting date of the employee is used to determine when tasks should be completed. The New Hire Task Templates list contains a little more information. The days to complete column holds a number that is used in conjunction with the start date of the employee to provide the due date of the task. The task description contains the description of how the employee accomplishes the task. This can include links to other resources, phone numbers of people to contact or other information on how the task might be completed.
With the lists have been designed, now we can turn the workflow used in the solution. One of the great capabilities in Nintex Workflow 2010 is to work with a collection of results (this is also available in the 2007 version of the product). In the workflow I’m building, I need to query the New Hire Task Templates list for the available tasks and then iterate through them to create my actual tasks for the new hire. Using SharePoint Designer Workflows, even in 2010, we cannot query a list of items and use the results to build other items. This normally requires code to accomplish.
Instead of finding the nearest SharePoint developer (I don’t really have to look that far, as I am one!), I open the new hires list and start creating a Nintex Workflow. The first thing I need to create is a new workflow variable to hold the collection of task templates. The ribbon in the workflow designer provides easy access to all of my workflow variables — and notice that I’m still “in” SharePoint:
With the new collection variable created, I access the Query List action from the Libraries and Lists section of the workflow actions and drag it onto my workflow design. This workflow action allows me to query a list for some or all of the items in the list. I can either use a view or a customized CAML query to retrieve the items from the list. When the query is executed, only the ID’s of the items are retrieved and stored in my collection variable, so I will still need to do a little work to create my individual tasks. This is done using more variables and looking up information, much like it would be done using SharePoint Designer.
After all of the ID’s have been retrieved, another useful action from the Logic and flow section called For each is needed. This action iterates through a collection variable allowing me to set the variables and create new tasks based on the information on the template. After a task is created, permissions are changed so that only the user and HR can see the task.
When all of the tasks have been created, the employee is notified via email that a new hire checklist has been completed for their review. The email contains a url to a customized page with a view of their tasks. As they complete the tasks in the list, they are removed from this view and HR is notified. This allows HR to follow up with the employee or the employee’s manager on each item as they are completed.
Using third party tools like Nintex Workflow can provide new avenues for developers to harness complex code without needing to open an IDE. This was a solution that could be accomplished with code, but in less than an hour I have a workflow that does some fairly complex logic. Additionally, if the requirements for the workflow change I can simply reopen the workflow and make those changes instead of having to go through the entire development process to redeploy a simple change.
If you would like more information concerning Nintex Workflow 2010, you can review the Nintex website. If you are ready to investigate implementing Nintex Workflow 2010 into your SharePoint solution, feel free to contact the Portals and Collaboration team at Tribridge to get started. Tell them that I sent you!