I first wrote about Universal Request during the Quebec release and found during that time that it was only available for Incident and HR Case Management which left me with some questions that I hope to answer here. If you're looking for a summary of what Universal Request is and how it differs from Interactions (or the deprecated New Call functionality) check out my previous post.
Previously I spent about an hour or so just scanning the Universal Request functionality to get an idea of what developers and users could expect to see. With this post I'm going to go deeper to understand and communicate how to use Universal Request and why, as I feel like there hasn't been a lot of conversation on this topic yet.
Universal Request for Request Management is being introduced with the Rome release and I want to mention the Rome release also included tie ins with Innovation Management (Ideas), Workplace Service Delivery, and Universal Task as well, which is great because when I wrote my post on Universal Task I wasn't really sure how it tied in with Universal Request despite sharing similar names.
Universal Request Configuration
I want to take a step back here and dig into Universal Request just a little more, because I didn't go very deep in my previous post. I really need to break this out in another post and probably will in the future because there's so much that Universal Request can do. Luckily, there is a Guided Setup for UR and for Services, so I'll focus on some bits and pieces I found while going through those. I will mention the Guided Setup goes through setting up Email, Chat, Virtual Agent, and Predictive Intelligence which I will not go into here.
Universal Request ships with its own roles, found here and some default assignment groups. I do want to mention there is an ACL for the snc_internal role to read/write Universal Requests, so most of the roles will be around fulfillers. For example, UR provides a Universal Request group and IT Routing group by default, but more than likely this will be converted to an existing Service Desk group, or perhaps a new Service Desk Tier group would be created for this purpose.
SLAs can be configured for Universal Request just like other task based records on the platform. I won't go into configuring SLAs here, just know ServiceNow ships some OOTB SLAs that can be configured for the organization's needs.
Universal Request Service Configuration
There's a Guided Setup for this too, so I recommend checking it out because looking at the modules themselves can be a bit overwhelming. I'll break down some of the concepts of configuring Universal Request for Services.
The naming of this seems a bit new to me, but a Service Set is basically a department within your organization. I do want to notate here there is a default Service Set called Universal Request that has the Universal Set flag set to true. You need at least one Universal Set to act as a default and catch URs that haven't been routed to a Department. There's a Transfer Mapping field links to a Direct Transfer Configuration record. The Direct Transfer Configuration record defines the fields that are mapped and copied between the Universal Request and target table.
Service Set Assignment Groups define the automatic routing of Universal Requests to Assignment Groups, for example the IT Department Service Set has an assignment group of IT Routing Group which is used to triage both Universal Requests and Incidents.
A Service has to be registered to utilize the routing and transfer capabilities in Universal Request. From what I can see, you can only have one Service Configuration per table. The wording seems a bit odd here, it looks like a 'Service' is what developers would traditionally refer to as a table, not a Service in the sense of Service Catalog or Application Service. Since I'm focusing on Request Management next, I'll point out the example of the IT Service Catalog Service Name, which uses the Requested Item (sc_req_item) Service Table. There is no Service Set set up for this, because the routing is handled by the RITM/Workflow/Flow itself. For something like Incident, there is the example of the IT Department Service Name, which uses the Incident Service Table, and the IT Department Service Set.
Service Assignment Groups link Assignment Groups to Services, and Service Sets if one is defined on the Service Configuration. At this point I got a little confused because I have a Service Set Assignment Group and now a Service Assignment Group, so I'll try to break this down even though I still can't make sense of the documentation wording on this.
Service Set Assignment Groups automatically route Universal Requests to the right Assignment Group within a Service Set, while Service Assignment Groups allow for the transfer of Universal Requests after Triage by the Service Set Assignment Group to Assignment Groups associated with the Service.
Universal Request ships with it's own UI Actions OOTB as well such as 'Accept, Assign to me, Close, Copy, etc.' Here's the documentation, but what it's basically saying is that you have a Service that isn't using Case, or Incident, or Request, or HR Case, that you have to create a UI Action for it which has been pretty standard everywhere, but I'm glad it's documented for those who are using this outside of the OOTB tables.
State Mappings control the state of the Universal Request based upon the State and Conditions of the Record table. For example, if a RITM is closed, then the UR state will change to Closed per the example below. You can also set fields via the Universal Request template when the state changes, such as Close Notes, State Reason, etc.
Direct Transfer Configuration
Direct Transfer Configurations map fields between Universal Requests and target table records. There is a Map fields automatically link that can be used, or this can be set up manually.
The Transfer Configuration record controls the actions taken on a departmental ticket, or what I'll call task based record (whatever is not the UR) once the task based record is transferred back to a UR or another department (Service Set). There's two sets of information to fill out on a Transfer Configuration record, the Transfer Information and Closure Information section.
You can create create business rules on your service i.e. task based table to automatically attach record inserts with a Universal Request. Here's the documentation on how to do this. An example is shipped with the Universal Request Integration for Incident Management plugin and is found on the Incident table named Attach as Universal Req Primary Ticket.
Task Effective Number
There's a new column on the Task table called task_effective_number. This field will contain the UR number if there is a UR associated with a record, and the OOTB notifications use this field when the UR for Incident/HR plugins are installed.
There is more setup that can be done such as suppressing notifications when a Universal Request is associated. An example of this are Incident notifications suppressed when it's set as the Primary Ticket on a Universal Request. Note: Since ServiceNow uses Request notifications OOTB these will need to be configured for RITM notifications instead if your organization is using them.
Other setup includes the Standard Ticket page which I covered in my first post, setting up the My Request filters that reflect in the My Requests widget on the portal, allowing Application Cross-Scope Privileges, and Registering Services that are Scoped Applications.
As a quick recap, Universal Request is meant to be that one end user facing record that can interface with other internal record types such as Incident, HR Case, and now Requests. This saves the end user from having to juggle multiple record numbers and deal with redundant notifications. In my opinion we're basically getting back to basics on simplifying things for the end user, while leaving all of the more complex ITIL/HR stuff in the background for the fulfillers.
Unlike Incident and HR, there's no separate plugin for this functionality, all that needs to be done is to enable a property called: sn_uni_req.com.snc.ur.request_integration. Note: One neat thing I found while going through the properties is a property to create a Universal Request when an email is received to a specific address or addresses. This seems cool because it's an easy way to set up inbound actions for UR while leaving any other Incident/RITM inbound actions in place.
Allow Catalog Item or Record Producer to Create Universal Request
It looks like existing Catalog Items or Record Producers can be configured to create Universal Requests. What I've noticed since there is a Service Configuration set by default for the sc_req_item table, the Universal Request Config section is visible on Record Producers. On Catalog Items, this section doesn't exist, I'm not sure why at the moment, but you can configure the fields on the form or list view.
There's a field called UR Certified that can be checked allow for the automatic creation and linkage between Catalog Items/Record Producers and Universal Requests. There's also a Requires Additional Review checkbox added that ticks the Needs resolution review field on the UR. I'll just use UR Certified for now.
As soon as I checked that box and ordered the item I can see it created a UR and a Request.
Since the UR Certified button was enabled on this Catalog Item, the RITM automatically became the Primary Ticket for the Universal Request, which signals to me there shouldn't be much configuration or customization to do to this if you're using RITMs rather than REQs.
Set up State Mapping/Transfer Configuration
There's a default state mapping for sc_req_item which can be configured for an organization's needs. There are also default Transfer Configuration records set up as well. I'll use the OOTB setup to explore working through URs and RITMs.
I played around with the state mapping and it seemed to work. There's also a new Create Request button on the Universal Request form, so Requests can be created from URs as well. It takes you through the Service Catalog just like an Interaction, etc. would. I did notice there is a message stating the UR can be closed if it's no longer needed from this avenue, which signals to me that using UR and RITM isn't an 'always' kind of situation, which leaves me with more questions on when it should be used.
Here's what the UR/RITM looks like when viewing it from the Service Portal. The widget shows the stages of the RITM while displaying the UR.
I did notice that while comments didn't seem to transfer between records in UI16, the comments from the RITM were visible on the UR when viewing it from the Service Portal and if a comment was entered on the UR, it's visible on the RITM when viewing it from the platform.
I'm looking forward to more information perhaps at Knowledge 22 about organizations using Universal Request out in the wild. The Request Management functionality seems promising since this was a large piece missing to me in Quebec. I'm interested to see if organizations will roll out Universal Request with multiple record types at once, or if it makes more sense to do this piece by piece, i.e. Incident, HR Case, Request, etc.
Rome also released Universal Request tie-ins with Innovation Management and Universal Task which I'll create future posts on to give them their own time and space and perhaps answer more of the questions I had as I explore more.