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

Fred Jean
Tera Expert

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.

10 REPLIES 10

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

jMarshal_0-1730227194800.png

 

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