Using Universal task to involve non IT user in a Service request flow

[Fred Jean]

Hello,

We have a need where a catalog item should trigger a (work)flow involving a number of steps and users including non IT users.

HR or legal users should be involved to perform some tasks or provide input at some stage. Obviously for that we would not want to use Service Operation Workspace nor build a new custom workspace. We are on an ITSM platform with Employee Center (No HRSD).

So I thought that could be a good opportunity to make use of Universal tasks.

Thus I have installed the plug in and done a few basic tests. Here are my findings :

Pros :

- enables to assign tasks to users on the Employee center portal

- tasks can actually be shown on the ESC OotB (once assigned to a user and state is work in progress)

Cons :

- Requires some minimal configuration to be useable

- When you use the complete button on a "Mark when complete" tasks, the task is actually closed (which is good) but when you submit the form of a "provide input" tasks, the task is not closed, you can submit it several times. Why ? How it that supposed to work ?

- when you submit that "provide input" tasks, I don"t see the provided input on the OotB form of the Universal task or RITM either on the Workspace or Core UI

- Tasks must actually be assigned to the user to be visible on the ESC (we would like it to work with groups also)

- Task are only visible on ESC once state is "Work in progress" (seems counter intuitive to me as the task is not actually in progress yet until taken/open by the user)

- Tasks on the ESC don't show the related task they are attached to (I created Universal task for a RITM and then have no information or link on the RITM on the ESC form)

Would you have suggestion on how to work around these issues while staying OotB as much as possible ?

Or would you think Universal tasks is not the right option for this use case ?

One important point would be to be able to see and work on tasks assigned to a group (not a user). For this I thought may be we could implement a custom widget similar to "My items" but taking the group into account.

[jMarshal]

Sorry @Fred Jean - my bad, I was thinking of UR, not task. I have no experience with Universal Task yet, though I will be surprised if ServiceNow has introduced the ability to assign tasks (records that are extended from the task table) to users (records that exist in sys_user or an extended table) without a fulfiller license...that's been a pretty hard line in platform for many years. I think you're on the right track though...you probably don't need a fulfiller license to do what you want to do, if it doesn't involve adjusting field data or assigning task records (unless something has changed with that as indicated above).

Since the product is so new, I'd say it's fine to open a case for this with Now Support...or try reaching out to your sales rep about being put in touch with a solutions consultant or product manager for Universal Task, specifically.

[Ryan S]

I think JMarshal was correct. Universal Task is intended for the Fulfiller to task the Requester with additional information. It sounds like what you need are additional fulfillment activities within the (work)flow which requires a fulfiller license. That doesn't have to be within ITSM as you could generate activities in other modules, but given that you only have ITSM I think you need to grant itil licenses to these other departments and assign them the task. To avoid having to train these users on the platform, you could look at exposing the tasks on the Employee Center but that seems a bit counter-intuitive the Employee Center isn't for that backend fulfillment.

[jMarshal]

This is what I was referring to, yes.

I do also assign ITIL licenses to non-IT users for the purpose of assigning fulfillment tasks to them. The way we got around the issue with exposing the tasks, was to give them native ui16 access and customized nav menus with custom roles (note - this involves a lot of changes to oob visibility lists for applications and modules). We then coupled that with some Data Filtration records to restrict access to request items and tasks that were not related to their specific use case. I tried/explored explicit roles - only assigning sn-request-read/sn-request-write to the fulfiller groups, but that didn't work as well as I had expected as I took for granted how many platform features/activity require itil and would need to be built-out and extended to the explicit role(s). We rely quite a bit on 'security by obscurity' and do not expect these non-IT fulfiller users to 'hack' the ui16 backend portal, to gain access to records in the incident/problem/change table(s) or anything...but if that was an issue, I could 'beef up' by adding more Data Filtration records or explore the explicit roles again (intentionaly removing sn-incident-write, from those groups for instance).

[Fred Jean]

Hello I don't quite follow you, you say "Universal Task is intended for the Fulfiller to task the Requester with additional information" => yes that's more or less what we would like to do, except that the tasks might for other people than the requester (but could still be end user type users, working thought the portal).
Are you saying that if I want to assign a Universal Task to someone else than the requester, then that user should have an itil licence ?

[Ryan S]

Are you saying that if I want to assign a Universal Task to someone else than the requester, then that user should have an itil licence ? -- YES

Ok, so how do we work around that? If the other person is on the Watch List, I think that lets them add comments via email. Basically anything working through email is probably the workaround but that's not fun.