Previously, I explored Universal Request, and touched base on Universal Task briefly, but at the time the docs sites weren't available for Universal Task. In this post, I'll dig deeper into the Universal Task plugin to see how it works in conjunction with Universal Request.
The scenario ServiceNow provides in their documentation is about an employee who has lost a laptop, needing to open an Incident regarding the loss, and then the agent working the Incident then needs to open a Request for a new laptop, providing the end-user with two different record numbers.
Universal Task is it's own plugin outside of the Universal Request plugin, and it looks like at first glance you don't have to use Universal Request to use Universal Tasks. Per the documentation Universal Tasks can be used for Universal Requests, Incidents, HR Cases, or vaguely a 'legal matter', so it seems like they can be used on multiple record types and don't have to be used with Universal Request exclusively. Per the Store documentation, they can be used for any ticket type that extends the task table.
Employee Service Center
I wanted to touch base on Employee Service Center, as this is what Universal Task is tied to for employees. Universal Tasks can be viewed by employees in the platform, but per the documentation employees can only add comments to the task and the watch list in the platform view. So it seems like the Employee Service Center is needed more than not for Universal Task if you're using them outside of agents. Employees can view and complete the Universal Task in the To-Do tab of the Employee Service Center.
Agents on the other hand can work the tasks within the platform and aren't beholden to Employee Service Center. This is something to keep in mind when you're deploying Universal Task and what kind of task types you're using and to who you expect to carry them out.
Universal Task Types
Out-of-the-box Universal Task ships with two task types, you can configure task types for your Service under Universal Task Configuration, which i'll touch base on in the walkthrough.
Submit Catalog Items - This task type does not automatically submit a Catalog Item via the Universal Task, rather it is a task to inform the assigned employee to submit a specific Catalog item.
Upload Documents - This task type informs employees to upload documents that may be necessary for their incident or request.
Note: What I found in setting these up is that you can't have multiple Universal Task Configurations on a table, so add all of the applicable task types in the configuration for the table, and if they need to be updated, then add them to the existing configuration. The one issue I could see with this is the Default assigned to, for example if you want Submit Catalog Item to default to Assigned to, and Upload Documents to default to Caller, you have to pick one and make sure it's manually updated when creating the Universal Task.
It looks like Task Types are just a choice list on the Universal Task Configurations sn_uni_task_config table, so I don't see a reason why you couldn't add your own, for fun I added in: Make Coffee (just make sure you're in the Universal Task scope or you can't select the Universal Task Configuration table for your choice)
Some fields to note:
Parent Table: The table the Universal Task is applied to
Task Types: Available task types
Default Assigned to: Who this task will apply to by default, for example Caller or Assigned to, but this can be changed when creating a Universal Task.
Universal Task Data Model
Universal Task Table: sn_uni_task_universal_task
Universal Task Configurations: sn_uni_task_config
Catalog Task Configurations: sn_uni_task_catalog_task_config
Base Task Configurations: sn_uni_task_base_task_config
Universal Task extends Task so it inherits of all the goodies, and it has its own state field values and priorities. Universal Tasks also ship with due dates and notifications out-of-the-box.
There are two OOTB UI Actions on a Universal Task record:
Submit: Creates the task, state is New, and no notification is sent.
Ready for work: Creates the task, and changes the state to Work in Progress, and sends a notification to the Assigned to field.
I noticed a Sibling Tasks related list on the Universal Task form. I couldn't find any documentation on it relating to Universal Task but noticed if any other Universal Tasks exist on the Parent record not only will they show under the Universal Task related list on the Parent, they will also show in the Sibling Task related list on the Universal Task form. One other thing I noticed is that for itil users the New button is disabled in the Platform view, but is available in the Workspace UI view so users can make new Universal Tasks this way, or you may just want to disable the New button here and use the UI Action you made to make it less confusing.
Universal Task Setup Walkthrough
Universal Task isn't installed by default on the platform, and doesn't get installed when you install Universal Request, so the first thing to do is install in your PDI or Sub-Production instance (if your company is wanting to use it). One thing to note that I read in the most recent Store documentation of the app (1.0.6 as of this post) is that the glide.enforce_security_scope.sn_uni_task property needs to be set to True in the Global scope, when I checked my PDI this was done automatically.
The first step after installing the Universal Task plugin is to configure UI Actions for Universal Tasks. It looks like you can use the same code provided in the docs for both the platform and in the Workspace Client Script section. I just named mine Assign Universal Task so I could locate it easily for this blog, and gave it an Action name of sysverb_assign_uni_task. I set it as a form button and a Workspace form button. Here's the script:
var gr = new GlideRecord("sn_uni_task_universal_task"); gr.initialize(); gr.setValue("parent",current.sys_id); action.openGlideRecord(gr); action.setReturnURL(current);
What's interesting is that I haven't seen action.openGlideRecord() before, but it looks like it's been around since London. This seems to be functionality geared towards Workspace, if anyone has anymore information about this please leave a comment, but this was a great easter egg to find when writing this article.
Next we add a Related List to the table we want to use Universal Tasks with, in my example I added it to the Incident form.
On my parent Incident, I set the Assignment group and Assigned to field for demo purposes, and you can see the Assign Universal Task UI Action I created. Once I click the UI Action the Universal Task form appears and automatically populates the Parent assignment group and Parent assigned to as well as the Assigned to field.
Under type, you can see the out-of-the-box types as well as the one I created, Make Coffee:
If I choose Submit Catalog Item as a type, I get the Catalog Item dropdown, and per documentation should be filtered to what the agent has access to (for me as an admin it's wide open)
I went ahead and clicked Ready for Work so it sets the state to Work In Progress and sends a notification to the Assigned to field.
I activated the Employee Service Center plugin on my PDI since I have the keys to the castle, but just keep in mind it is a paid plugin, it's not a pre-requisite to use Universal Task, but it is if you're assigning tasks to anyone other that agents(fulfillers). To be clear this is going to lean more on the HR side of the house but just for visuals. I impersonated a user who could access Employee Service Center (Aileen Mottern) and clicked navigated to Self-Service > Employee Service Center. Universal Tasks are shown underneath the To-dos menu item. I navigated to a Universal Task which instructed me to Upload Documents and put in an attachment.
Once I click Complete the Universal Task is now in the Completed tab.
Agents can see Universal Tasks assigned to them via the Platform UI module Universal Tasks > Assigned to me or by going to Agent Workspace (or any Workspace configured to use Universal Tasks)
This is one of the first plugins that I've seen shipped with Mobile documentation, so I'll touch base on it. The documentation states the Now Mobile application, and this seems to work pretty seamless out-of-the-box. I checked Now Agent and I think some configuration would be needed to show Universal Tasks there.
I assigned a Universal Task to myself and upon logging into Now Mobile I can see there's a Task showing in My Tasks, clicking into My Tasks I can see the Universal Task, the description in the header is actually the short description on the Parent Incident this is linked to.
Clicking on Learn More and Updates will show me more details about the Task and allow me to leave comments and attachments.
Since my Universal Task is to Submit a Catalog Item I can click on that link and it will take me directly to the Catalog Item, and once I've ordered the Item it will complete the Universal Task out automatically.
Universal Tasks seem pretty useful in my opinion and answered some questions I had when writing about Universal Request, as I saw Universal Request didn't extend to Service Catalog Requests. I'm assuming you can use both in conjunction with one another and am really excited to see how customers begin implementing this. I've seen Incident Tasks used in the past to meet this type of functionality, but they're really not meant for housing to do items such as Catalog Requests and further complicate the multiple task number issue. I followed ServiceNow's scenario of a user opening an Incident for losing a laptop, but I can see where Universal Request would be better suited for this, because as soon as I request a laptop there's a REQ number out there, the Universal Task is closed, and then I need to do something with the Incident, so there's still a gap here with the multiple numbers floating around, rather the Incident could be tied to a Universal Request while all of this is happening so the end user only sees the one Universal Request number, but the REQ number is still out there when using Universal Task. I also see when creating a REQ from a UT, there's no linkage or indicator that I submitted the REQ on the UT record, but I did notice it's on the Parent Incident record as a comment and if I navigate to the REQ the Parent field has been set to the Incident. For fun I did the following:
Opened a new Universal Request
Created an Incident associated to the UR
Created a UT on the INC
Submitted a Catalog Item REQ (which is now associated to the INC)
I noticed that the REQ On Behalf notification did go out to the user, even though the parent INC is associated to a UR and the UR suppresses notifications from its Primary ticket.
It seems like some configuration would need to be done especially in the scenario I just performed to make sure the user only gets the UR notifications and not notifications from the REQ. I also noticed that in the Service Portal the user sees the Universal Request as well as the REQ created from the UT associated to the INC that is associated to the UR so this is something to keep in mind as well when configuring this on your instance.