As I start to use Nintex Workflow for Office 365 more, there are a number of actions which I miss from the on premises version.
Whilst it’s only a matter of time until we have feature parity / cloud first functionality, in the meantime there is a functional gap.
One such gap is the ability to easily capture information from a task assignee, much like we can with the on premises “Request data” action. By default the “Assign a task” action in the Office 365 version is quite limited and focuses on assigning a basic task that needs to be completed.
Through a combination of Nintex Workflow for Office 365 and Nintex Forms for Office 365 you can create functionality very similar to that of the Request data functionality. Hopefully the below becomes redundant as this becomes a bit more seamless with native functionality.
Firstly, let’s set the scene slightly and look at why we might want to do this.
If you are creating a business process that involves not just driving a process, but also capturing information along the way (e.g. a Starters/leavers or onboarding process), then it is much simpler to assign a task to someone and capture all information you require within a single task response form. We can then store these responses and direct the rest of the workflow accordingly.
There may be a cleaner approach, however the below works for me.
At a high level, I create a content type to hold the task information that is assigned to someone to complete. That task form is then customised, with the resulting information then being queried from the workflow tasks list to then be actioned within your workflow.
We need to create a new site content type to align to the user task that we want to capture information from. With the on premises Request data action, this is done automatically for you behind the scenes. For Office 365, it’s not too painful as we can see below.
To create our new content type, we simply need to ensure that our parent content type is that of Workflow Task (SharePoint 2013). This allows Nintex to recognise this, and more importantly provides us with the key status fields that a workflow task needs to contain behind the scenes.
By default you will see all of these fields when you respond to a task. Don’t worry about this – we will sort this aspect out soon!
Now we need to add a column to this content type for each field that we want to capture. In this example I want to ask the task assignee to provide an account name and email address.
Now that the content type is setup, create a new workflow on your list of choice. Make sure that you have the same fields added to that list. This allows for the captured information to be saved against the list item which the workflow was run from.
Begin by adding a basic Assign a task action.
Start to configure this task – for the first few sections this should be quite straight-forward.
The trick in our example comes from the Outcome Options section of the action properties. Within the Task content type we are able to select the content type we made above (i.e. since it was based on Workflow Task). Another important item to configure is the Task Item ID. We will use this to extract the values provided and store them as part of the workflow. One thing you may not expect here is that the Task Item ID is actually a GUID and not a simple list ID. More on this later.
Next we want to create an Office 365 query list action for each field that we wanted to capture. This action should target our Workflow Tasks list. In our case, see how this action can be created to obtain the email address saved for our task response. As per the above, we have an in-built GUID column to reference so we can essentially query our particular workflow task and pull back the Email Address that was provided as part of the response.
When we query the Workflow Tasks list, the resulting fields are stored within an array/dictionary/collection. We need to use the Get an Item from a Dictionary action to extract this as follows.
With this building block in place:
• Create task
• Query the Workflow Tasks list
• Extract the field from the dictionary
We can now enhance the workflow slightly to add some status information and also extract multiple fields. To keep things simple, I actually run multiple query actions for each field in parallel vs. trying to pull back all fields at once for subsequent parsing. The net result here is the same.
After publishing the workflow, our custom content type should now be available on our Workflow Tasks list.
Customise the task form:
Next we want to navigate to the Workflow Tasks list and open Nintex Forms for Office 365. Since we have more than one content type on this list, we are presented with a choice of which content type to customise. For our example, we want to customise the Request Data Demo content type.
By default we see a nice looking Nintex Form, however all fields encapsulated within the content type are displayed.
The next step is to remove all fields aside from the Task Status and your custom fields (Account Name and Email Address for our example). The reason we need to preserve the Task Status field is that this determines whether Nintex Workflow views a task as being completed or not. If we were to remove this, any completed task would simply close the task form and not actually trigger a completed event.
There is a hack for this requirement, simply drag the field somewhere where it will be less obvious such as over an image, then send it to the “back” layer so it’s in effect hidden by the image.
The resulting form is much cleaner and similar to what we would have expected to be auto generated in the On Premises world for the Request data action.
Now double click the Save button and expand the advanced section. We need to add an on click event to update the task status to be completed. From an end user perspective you could create a separate button (e.g. submit) which would enable a form with more fields to be edited and saved prior to submission.
var tempVariable = $NWFS(‘#’ + taskStatusField);
Once we run our workflow we have a user task generated as expected within our Workflow Tasks list.
We can now edit the task and provide the requested information.
Upon saving we can see that the task has been “completed” in the eyes of SharePoint and Nintex Workflow.
Navigating back up to our source list, the provided information has now been stored in the associated columns against our item.
This can easily be scaled up and replicated for numerous user tasks to facilitate complex form requirements such as those supporting a starters and leavers system. As with the pace of enhancements at the moment, I suspect it won’t be long before this workaround is redundant – however in the meantime I hope you find it useful.