Service Catalog Items - Managing Required Fields After Submission (sc_task licensing)

[melcock]

We've been slowly ramping up our ServiceNow implementation and I'm running into a recurring theme where I could use some advice on where to go next.

Many of the pending workflows have multiple levels of data submission.  For example, one workflow concerns requesting a new record in a system.  Here's the current process:

• Initial submission
• First Approver is required to complete 1-2 fields to provide the billing info
• The second approver verifies that everything is correct
• The admin of the system creates the record and must provide the ID number as the final step

If I were to assign these as Approvals there is nothing that forces the required fields to be completed even if I mark them as Mandatory at that step.  I can create Catalog Tasks to require the necessary info, but that forces them into a different interface and I don't know how that impacts our licensing.

Ideally, we find a way to enforce required fields on the Service Portal alongside approvals.  Less ideal is assigning Tasks to a larger population of users.

Has anyone run into this and what is your solution?  Can we assign Tasks to end-users and not use up our "Fulfiller" license total?  None of them would have ITIL access.

Thanks!

[Michael Jones -]

You definitely can't assign tasks to a user without roles and allow them to complete those tasks - that would completely bypass the purpose of a distinction being made between an end-user, an approver, and a fulfiller.

This type of scenario does come up from time to time and, unfortunately there is no simple answer or solution. Generally speaking, updates to a record after the initial creation require that the user have a role that allows it. You are definitely starting to tread across the line between end-user and fulfiller at that point. Approvers can do just that - provide approval - but anything outside of that, performed directly in the UI or Portal against a task/form, is a licensed activity.

The key here is that the activity can't occur directly in the UI or the Portal. Fair warning, the solutions that I have seen have not been scalable; they were applied to meet specific needs and not something used liberally across multiple processes. 

One method I have seen would be to generate a notification to the user who needs to provide the update and, as part of that notification, provide a link that opens a formatted reply template that they can complete and send back - the template needs to contain something unique in the subject so that you can create an inbound email action that takes the template, pulls out the values you are looking for, and then updates the appropriate record.variables. I have usually seen this used in conjunction with a "wait for condition" that just waits until the require values have been added before progressing the workflow.

A second method I have seen, which might be blurring the lines a little, would be to create a custom portal widget that doesn't directly display the form or item itself, but accepts URL parameters that would display a simple form with whatever input boxes or choices you need the user to select. Again, a notification is sent, with a formatted URL that the user can click, provide the information and click done - and then the widget makes the necessary updates to the item via server-scripting. A wait for condition works in this scenario as well. 

Both options require some significant development time to implement and present challenges. The first option somewhat aligns with existing use-cases such as allowing an approval via email even for users without a role. The second option is a little more grey-area; depending to what extent it is utilized and your point of view, it might be considered as infringing on a licensed role. 

I hope this helps!

If this was helpful, or correct, please be kind and mark the answer appropriately.

Michael Jones - Proud member of the GlideFast Consulting Team!

[melcock]

I appreciate the info, but I wanted to follow up to see if I understood what is possible.

To clarify: I'm looking to allow users to update a couple of Variables on the Item in the second round of the submission.  I spun up a fresh Dev Instance, and the OOB security allows the requester/Requested For users to edit Variables. Does that mean that they could edit a Variable without shifting to Fulfiller?

It doesn't solve the issue of enforcing Required fields, but at least I would be able to use that as a solution potentially.

Thanks!

[Michael Jones -]

Yes, the creator of the request, or the one it is created for, can update variables and that does not require a license - again - only requests they have created themselves or where they are selected as the Requested For. They are only able to update the variables when accessing the Requested Item itself, not when approving, and they can't access a task record. 

So, in theory, you could use that as a solution; require the requester to update the request as needed, just not strictly in the context of performing an approval (those would remain different activities on different tables). 

I hope this helps!

If this was helpful, or correct, please be kind and mark the answer appropriately.

Michael Jones - Proud member of the GlideFast Consulting Team!

[melcock]

That may be our solution, plus some creative workflow looping.

Hopefully, one last question: Our main Approval page on the Service Portal has both the Approval Widget as well as a widget that displays the Requested Item.  I assume that counts for "accessing the Requested Item itself"? That widget has a separate "Save" button that saves the Item.

Thanks!