After the Quebec release I spent about an hour looking into Universal Task and at that time wasn't sure how they tied into Universal Request despite sharing the name. At the time I thought they bridged the gap for Request Management, but since the release of Universal Request for Request Management I know now that isn't the case. This post explores the tie in between both and hopefully uncovers the actual intended use of Universal Task. If you're looking for basic setup, screenshots, etc. check out the first link above as I covered most of that in my first post.
Per the Rome documentation, Universal Request can be used in conjunction with Universal Task to allow agents to task fulfillers, track progress, and provide resolution.
There isn't a lot of documentation on this at the moment, but we do need to configure a service to use Universal Task. What I've found is that the terminology of service can be translated into table, i.e. incident, hr case, custom task table and not so much the concept of Application Services or Service Catalog.
I covered previously that there is a UI Action that can be configured on a table to create a Universal Task. The documentation is so vague that I'm assuming the only difference between setting up Universal Task on something like Incident versus Universal Request, is that we need to actually set it up on Universal Request. I'll recap the UI Action:
Download the Universal Task plugin if you haven't already or upgrade it
Configure the glide.enforce_security_scope.sn_uni_task property to True
Create a new UI Action
I followed along with the documentation and created an Assign Task button for the Universal Request table using the provided code:
var urGr = new GlideRecord("sn_uni_task_universal_task"); urGr.newRecord(); urGr.setValue("parent",current.sys_id); action.openGlideRecord(urGr); action.setReturnURL(current);
I mentioned previously that action.openGlideRecord() is pretty cool and created a post about it.
In order to finalize the creation of a Universal Task on the Universal Request table, I do need to set up a task type for our service via the Universal Task Configuration (sn_uni_task_config) table. Check out my previous post on Universal Tasks for more in depth information on Task types. I will mention there are some new task types added as of Rome: Mark when Complete, Collect Employee Input, and Checklist.
The next step is to add a related list (Universal Task -> Parent) to the Universal Request form to display Universal Tasks.
This set up seemed pretty simple. I honestly can't remember if this was available and just not documented in Quebec or not. It was nice to finally clarify that there were plans to use Universal Request with Request Management as of Rome, and that Universal Task is not meant as a stop gap solution for this. One thing I want to mention is the scenario ServiceNow provided in the documentation:
An employee has a lost laptop, they open an incident, and the fulfiller needs additional information, so they open a Universal Task to get that information. The fulfiller then tasks the employee to order a new laptop by submitting a catalog item under the Incident rather than closing the Incident and opening a Request for the employee.
At first thought, I wondered why an Incident Task wasn't used, but from reading Incident Tasks are meant for fulfillers to communicate and request work from assignment groups other than the one assigned to the Incident, and Universal Tasks can be used to gather information from end users. I guess this is where clearly defined Universal Task Types come into play, because a Universal Task must have a task type by default, and they must be defined so they really can't be used for anything unlike an Incident task.
I would love to see more information from ServiceNow for some side by side comparisons on which functionality should be used when rather than combing through wording on the product documentation. I think for this to really take off, ServiceNow will need to provide some more scenarios and examples rather than just leaving it up to customers because the scenario above isn't something that most customers are just going to come up with in my opinion. It does require two extra tasks for an employee/end user to complete and at the moment there's not a lot of information on the benefits of this versus sending the employee a comment to attach a file to a record.
I can see where using Universal Request with Request Management and Universal Tasks could be useful, as most of us have experienced the RITM/Task communication issues. In this scenario an end user would see their Universal Request rather than the RITM, and can be assigned a Universal Task either from the UR or RITM to provide additional information so the fulfiller doesn't need to go to the RITM to communicate (or most of us have set up some syncing mechanism). I tried this out just for fun:
I created a Universal Request from a Catalog Item (documented here) and set up a UI Action/Related List/Task Type (assigning to the Requested for user) on the sc_req_item table.
Per the documentation, I created a My Request Filter record to display Universal Tasks within the list of requests on the portal.
Here's what it looks like on the Service Portal under the Requests page:
I think setting up something like a To Dos on the Service Portal to mimic the Employee Service Center would be a better way of presenting this, as you can see now we have yet another number on the Requests page to follow. I didn't configure the UR or RITM number to display as a secondary field in the list, but this would make it more clear to the end user. ServiceNow does mention this in this product documentation under the Requester experience section, and suggests adding a Task tab to the Standard Ticket page.
Here's what this looks like:
Honestly this is pretty cool, I haven't done much with Standard Ticket Configurations but now I want to dive deeper on the subject. This is kind of buried in a one liner in their documentation, but the ability to show end users their tasks within a Universal Request or other record type seems very useful and powerful. From the screenshot, I added a Universal Task to the Universal Request itself, and I also added one to the RITM the Universal Request is associated to, and both of them show up on the tab.
I still haven't gone all the way down the rabbit-hole when it comes to Universal Tasks as there is more configuration that can be done, but I do have a better idea on how to use them in conjunction with Universal Requests now, and how they can be beneficial when gathering information or materials from employees/end users rather than relying on sending comments back and forth from a record.