question Using Universal task to involve non IT user in a Service request flow in Employee Slate and Employee Center forum

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

Fred Jean — Thu, 23 May 2024 14:42:20 GMT

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.

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

jMarshal — Thu, 23 May 2024 14:11:21 GMT

What license are you assigning these employees? -- it seems like you are not assigning a fulfiller role to them (you mention that you only subscribe to ITSM).

The "provide input" tasks are more of a way to conveniently get comments on an existing requested item, not actually take an action on a task (adjust status, reassign, etc.) -- If you want them to adjust fields on tasks beyond the comments (like status fields) or be assigned tasks that are actionable (besides the non-actionable "provide input" ones), you need to give them a fulfiller license (itil, for instance).

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

Fred Jean — Thu, 23 May 2024 14:23:00 GMT

Licence is another question (but not necessarily an issue). I don't think we should/would need fulfiller; was wondering about stakeholder though.
Requesting comments or additional input or requesting action (with task type "Mark when complete") is actually what we need, we don't expect them to adjust fields on the RITM or tasks (but still to know the context of these Universal tasks, information about the related RITM is needed).

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

jMarshal — Thu, 23 May 2024 15:47:56 GMT

I suppose I could be wrong, you'd need to speak with your specific sales/account rep at ServiceNow...but I'm pretty sure that you do need a platform fulfiller license to adjust fields (beyond "comments") on an assignable task record or have that task record assigned to a user.

Business Stakeholder will allows you view-only access to all ITSM records, approval access as well as some specific PA access...but I think that's it. Installed with Business Stakeholder (servicenow.com)

...so if you are only looking to view and add comments to RITM records which are "requested for" a different user, a business stakeholder would be able to do that OOB...but I still do not think it would accomplish your goal (if this is your end goal) of "closing" the "provide information" tasks in EC.

ServiceNow also offers webinars with product experts and you may want to sign up for one related to Employee Centre and/or Universal Request. When it comes to Employee Centre specifically, I have been working with @Smriti_Gupta (smriti.gupta@servicenow.com) who is an outbound product manager for EC and this series has been very helpful!

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

Fred Jean — Thu, 23 May 2024 16:07:55 GMT

Thanks for your feedback, but again I don't think we need ability to "adjust" fields on taks; using the Universal task with "provide input" type is something different that I believe is meant for end users. But anyway if a fulfiller licence is needed may be we can have it.

My concerns are more about the usability of Universal tasks (not Universal Requests) for our purpose. There isn't much material on this.

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

jMarshal — Thu, 23 May 2024 18:10:15 GMT

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.

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

Ryan S — Sat, 26 Oct 2024 19:41:09 GMT

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.

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

jMarshal — Mon, 28 Oct 2024 16:16:27 GMT

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).

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

Fred Jean — Mon, 28 Oct 2024 16:38:17 GMT

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 ?

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

Ryan S — Mon, 28 Oct 2024 17:50:56 GMT

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.

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

jMarshal — Tue, 29 Oct 2024 19:31:05 GMT

@Fred Jean - The problem here being that non-fulfiller users are only licensed to access requests where they are the requestor. Authenticated users without a fulfiller role do not have access to any records on the task table (including extended tables) where they are not the requestor.

Think of the "task" that we (myself and @Ryan S) are referring to, as more like a notification. A notification that additional information/input is required, for the licensed user (fulfiller, itil, etc.) to complete the task that they are assigned. Whereas a standard notification is one-way (a notification is sent, not always received-back or actioned), a task (such as the one described here, in the context of Universal Task) requires the recipient of this "notification" to action it (accept/acknowledge/close), else it can keep triggering (to remind the end user). This solution is more "slick" than one which uses scheduled jobs to check the status of open tasks and send traditional notifications as "reminders", when info is needed to close a task.

This is why, when you log in to Now Support, you have a "notifications" section and a "task" section at the top...one is using the tasks we are describing to have ServiceNow communicate actionable requirements to us as customers ("accept as solution", for instance).

The other way around this would be to leverage "business_stakeholder" licensing/roles. This would provide a non-fulfiller-user read access to all tasks (and project records too, FYI), not just tasks where they are the requestor.

...so those users can action tasks assigned to them (universal tasks only), related to items that are requested by/for other users. However, know that the "base-task" record itself still cannot be assigned to those users...in fact, I believe that ServiceNow doesn't even allow them to be members of a group which could be assigned a task-table-extended record (like an incident), regardless of their permissions/role. To my understanding, this is enforced by way of license audits (automated) - not by actually disallowing the assignment of the task.

...so there is some creative user/persona management that would go into using the platform in this way...but you could probably do it without violating your license agreement. Of course, you would want to proceed with caution at your own risk after consulting with your sales rep, safe harbour, etc etc etc