cancel
Showing results for 
Search instead for 
Did you mean: 

A Different Approach for Task Notifications

Nintex Employee
Nintex Employee
6 2 1,823

With the encroaching end of a major effort I have been a part of for the better part of this year, the time has come to look back and review all the things that were encountered and see if they could have been done better. I wanted to take a moment and share something that was asked of me mid-way through this project and changed how I approached the workflow.

A Bit of Background

At the core, this is nothing more than an approval process. That said, it goes through 9 different approvals ranging from service reps, to field reps, to engineers looking at installed equipment. In total, there are 5 different groups that have to touch this and within each of those groups, it may be assigned to a different user depending on geo-location.

So you may already see where I am taking this, but the issue that arose is how can we assign a task to someone but allow for someone else to jump in and take over?

Delegation right? Well delegation requires the assigned user to do the delegation. What happens if that user is unavailable? What if the supervisor needs to step in or have a "secondary" user process the step that it is on?

After some thinking I landed on assigning the task to the entire group, but only sending the notification to the specific user. This allows for the entire team to have access to complete the task if needed, but still only notifies the proper "assigned" user to complete the task.

How I Did It

This approach is simple enough.

Create the task, but do not send a notification, then, in a parallel action, send the notification.

Within the task itself, you will need to capture the task ID within a workflow variable (integer):

You will also need to set the delivery type to "None" so that the task does not generate a notification:

On the parallel branch, you will need to put a slight pause in the workflow so that the system can create the task.

Immediately after the pause step, you can add your notification. Within your notification, you will need to build a task URL using the task ID variable. So something like this:

{Common:WebURL}/Lists/Workflow Tasks/EditForm.aspx?ID={WorkflowVariable:taskID}

If you do not add a pause, the task ID variable may be blank/empty because the task ID has not been set and you are using it to create the task URL.

And that is it! You now have a task assigned to a group of users, but are only notifying a specific user(s) that it exists. This allows you and the assigned team the flexibility to shift work when needed without changing anything within the task or workflow and without bombarding users with task notifications.

Final Thoughts

As always, there is probably a million ways to approach this and I am eager to hear what others have to say and how they would tackle this. Let me know in the comments below and as always, hope this helps!

2 Comments
scrawford
Nintex Newbie

Hi there @jesse_mchargue ,

 

The Task ID is only generated once the task has been responded to though right?  So you have to wait for the respondent to answer before the email notification goes out?

Nintex Employee
Nintex Employee

@scrawford

 

The Task ID is the SharePoint list item ID of the created task. This means that the variable holds the task item ID, which we can then use to build a URL on the fly as needed. The task ID is genereated once task is created, so in my scenario above, the task is created and I am storing the ID in a variable. In a parallel branch, I am pausing for about 5 minutes (to allow for the task to be created) and then emailing a user a manually created URL that leverages the task ID.