How to get Task Comments and more in Nintex Workflow for 365.
Note: Task ID’s have been added to Assign a task as of October 2017. See Office365 - Query Task IDs for Multiple Approvers! for details.
This is the first in a series of blogs that will describe useful building blocks for many automation applications. The final blog will pull these all together in a simple but illustrative example.
Introduction:
In SharePoint online the “Start a task process” is the action that allows assigning a task to multiple assignees. Task IDs are not available from the SharePoint online task engine for the “Start a Task Process” action. As a result Nintex “Start a Task Process” does not provide the facility for capturing task IDs. It simply returns the outcome of the task, with no information as to how that outcome was derived (who selected one outcome and with what comments etc.).
It is therefore not obvious how one can capture the task information, a need expressed by many Nintex customers.
Many users wish to capture the respondent’s comments, confirm who responded and when. All this can be done.
Problem statement:
Each run (instance) of the workflow will write its tasks to the same task list. Also task lists can be used by for more than one workflow design and therefore all tasks generated by those workflows are written to that task list as well. The problem is to identify which task items correspond to which instance of a workflow and also to which task action within that workflow (if there is more than one task action in the workflow design).
This problem can be further broken down into two parts:
- Identify all task list items that belong to the workflow instance (run).
- Of these, identify which ones correspond to which task action in the workflow design?
What we need is an identifier that makes the above distinctions. If we had this, then we could simply query the task list (using this identifier in the query).
Solution:
The 365 platform provides us with a globally unique identifier (GUID) for each workflow instance. This fits with sub-problem 1. above, the workflow GUID uniquely identifies the workflow instance. We can capture this and store it in a workflow variable (e.g. WfInstGuid) using the Nintex “Set Workflow Variable” action.
- Variable WfInstGuid] Value Equals lWorkflow Context] uInstance ID]
It is up to the designer to give a name to a task action, so if we use a different name for each task action within the workflow we solve sub-problem 2.
Combining these two gives us a unique task identifier that identifies the task list items (tasks) that belong to the workflow instance and the task action of interest. What remains is to inject this into the task list item so we can query against it.
The “Start a task process” action provides two avenues for writing it to the task item, namely the task title or the task description. Either will work for our needs. I have used the task title in the example workflow.
In summary.
- Capture the workflow instance ID using a “Set workflow variable” action – e.g. into rWfInstID].
- Assign a distinct name (distinct in the workflow that is) to the task action. Store this in a variable using a “Set workflow variable”– e.g. into nTaskName1]
- Combine the two (concatenate) and store into a third workflow variable – e.g. into rTaskName1ID] – the unique identifier.
- When configuring the “Start a task process” action set the task Title to this unique identifier – e.g. nTaskName1ID].
- Note: if you still want a descriptive Task Title then append the unique identifier to the end of your Task Title.
When the workflow runs the “Start a Task Process” action it will create tasks with the value stored in cTaskName1ID] included in the task name in the task list. This now identifies all tasks that belong to that workflow instance and that task action.
Querying the task list.
The task list is a list in SP online that can be queried using the “Query List” action. In our case, we have set up the Task name column as the column that contains the query criterion to extract the tasks (task list items) that we need. In the query, we can return any of the columns in the task list of interest e.g. Assigned to, Modified By, Comments, Completed, Due date, Outcome etc.
The Query criterion is then
- Task Name contains {Variable:TaskName1ID} and
- Task Status is not equal to Not Started (we only want those tasks that have been completed).
- “Query List” returns the values for all task list items that meet the criteria, into a collection variable. This makes it easy to process the returned results in a “For each” loop.
Conclusion:
This strategy allows the workflow designer to access all the information on the task list for a workflow instance (run) and the desired task action within the workflow.
This allows a rich set of functionality that the designer can provide in the workflow design e.g.
- Capturing comments
- Who replied with what response?
- The task due date verses actual date for reporting
- Status of task responses after or before task completion (before task completion requires some additional design solutions – to be covered in a future blog)
- Capturing audit information or reporting, management control or formal audit and record needs.
- Detecting non-compliance i.e. if the person who completed the task was not the person who it was assigned to.
Word of caution: Although one can query for the Task ID using this method, writing to the Task list, e.g. to update a task, may not prove to be reliable. The workflow engine may lock the record for its processing that could cause writing to the list to fail and possibly the workflow to terminate. This is because the SharePoint task engine is orchestrating task list updates and will lock the list item at any time. Any attempt you make to write to the task list may sometimes work and sometimes fail, depending on timing of competing task list updates from the SharePoint task engine.
Attached is a workflow.nwp file that illustrates the above pattern.
Explaining the workflow:
The example workflow is an overly simplistic expense approval for the purpose of just illustrating the querying of a task list to get details of the task respondents’ decisions and comments.
This first section is initiating workflow variables and updating the status of the workflow on the list. The second action is where we capture the workflow instance ID (GUID), and the third action where we assign a unique task name.
The next step is to create the task using the Start a task process” action. Start a task process assigns tasks to multiple respondents and tracks their responses to their tasks. When sufficient respondents have replied as to give an outcome (as specified in the task settings) then it will proceed down the respective outcome branch. In our configuration of the task we specify the task name as our variable that contains our unique task name and workflow instance ID. So all responses to this task in the same instance of the workflow execution will contain this unique task name.
In this simplified example the task outcome is stored into a variable to write back to the original list item.
This task makes use of the Nintex task form for the respondents to fill in their task responses.
The next step is to query the task list, after the task action has completed. This is where we use our carefully constructed task title to select only those tasks in the task list that are from this workflow instance and task.
Also in the Query action we now store each task list column that we want into a collection variable.
Having captured the information we want for the task, the workflow now processes the collections in a For-each loop and builds up a multiline text field that records the respondents and their decision and comments. It updates the list item that is the subject of this workflow using an Update list action. And finally the outcome for the whole task is written back to the list item.
In this way any information that is included in the Task List is made available for presenting to users, capturing for records and management or audit review. Check all the task list columns (not just those that are displayed by the default view) for any information that you would find useful for your application.
Hint: for performance you may wish to create a dedicated Task list for this workflow. This will maintain query performance.
