Best practices: add tasks to REQ/RITM ad hoc?

JP-ODU
Tera Guru

‎06-08-2020 08:18 AM

A team has been working on a workflow and catalog item to standardize their process, but the emerging need has been the ability to sometimes add non-standard tasks, not already covered in the workflow. They'd ideally like these new ad hoc tasks to fall into the existing workflow and relate back to the relevant RITM/REQ. 

So, my question is: is that possible? What's the best means of accomplishing it?

1) one solution I found, here: https://community.servicenow.com/community?id=community_question&sys_id=7fc5c721db1cdbc01dcaf3231f96..., seems to be a adding a generic request catalog item but that won't satisfy the request that the task be related back to the original request, it generates a new one

2) I'm curious about perhaps adding a role that has ACL write permission to the task table, thus permitting users to add tasks under the RITM, and thus it'll relate to the RITM and back to the REQ? Does anyone have experience with this approach?

Labels:
0 Helpfuls
  • 3,945 Views
5 REPLIES 5

Sam Ogden
Tera Guru

‎06-08-2020 08:30 AM

Hi JP-ODU,

We allow for additional catalog tasks to be manually created.  Users can only do this via the related list on the RITM record to ensure that the catalog task is correctly associated to the RITM and we don't end up with orphaned catalog tasks.

We then added a wait for condition before the complete stage with the following script:

var gr_tsk = new GlideRecod("sc_task");
gr_tsk.addQuery('request_item', current.sys_id);
gr_tsk.addQuery('state', '!=', '3');
gr_tsk.addQuery('state', '!=', '4');
gr_tsk.addQuery('state', '!=', '7');
gr_tsk.addQuery('wf_activity', '');
gr_tsk.query();
if(gr_tsk.next()) {
answer = false;
} else {
answer = true;
}

We also needed to add a business rule on the sc_task table which forces the workflow to re-run executing activities when a task that is not governed by the workflow is closed.

Business rule is after update with the condition:

current.wf_activity.isNil() && current.active.changesTo(false)

Script:

forceReqItemUpdate();

function forceReqItemUpdate() {
   var wf = new Workflow();
   var ri = new GlideRecord("sc_req_item");
   if (ri.get(current.request_item)) {
      wf.runFlows(ri, 'update');
   }
}

Without this business rule the workflow would just stay at the wait condition activity until an update was performed on the RITM.

Hope this helps

Sam

JP-ODU
Tera Guru
In response to Sam Ogden

‎06-08-2020 09:05 AM

It sounds like you've got a very sophisticated approach to exactly what I was looking for, this is great! Could you also share with me (sorry: SN newb) how you chose to control users making tasks (am I thinking correctly in using ACL?)

0 Helpfuls

Sam Ogden
Tera Guru
In response to JP-ODU

‎06-08-2020 11:26 AM

Hi,

On the sc_task table we amended the list control (right click on header of a column in the list > Configure > List control), to 'Omit new button':

find_real_file.png

This prevented users from creating catalog task manually from the main list view, which prevented them from creating orphaned catalog tasks.

The on the catalog task > Request Item related list we have the following 'Omit new condition' which prevents a user creating a new task on a closed RITM.  If you can't see the omit condition fields @Mark Roethof  has this article going through them

find_real_file.png

 

We just have the OOB created ACL on catalog task for users with ITIL or catalog_admin role.

If you need to restrict it any further you could create additional ACLs for the conditions you require or add additional arguments in the omit conditons.

Hope this helps

Thanks

Sam

Preview file
37 KB
Preview file
22 KB

Gaurav Shirsat
Mega Sage

‎06-08-2020 08:31 AM

Hi JD ODU

  • I'd relate this to an Amazon shopping experience.
  • The request is your Amazon order. It has an order number, your payment info, your shipping info and other information related to your overall order.
  • The items are your individual items in your Amazon order. For example, if you ordered 2 books, a monitor and a mouse, those are your items as part of your order.
  • Each item probably has its own workflow. Some ship from amazon, some ship from other suppliers. These would be the tasks for the items and make up the workflow for each item.
  • As the customer (or end user) i care about the request and how it pertains to my items. My request (Amazon order # 123456789) tells me what I ordered, my order status for each of my items and how far along I am. The end user gets this exact same view in Service Now. If I go in through self service and check the status of a Request, I can see, graphically, the status of my items under my request (the stages of these items are determined by the workflows for the items).
  • The request can handle maybe an overall approval process if needed (for instance, using the OOB example for approvals on orders over $1000). The items have their own workflows that are required to get the item from ordering through fulfillment. The tasks make up the individual work to complete those workflows.

also refer the below scenario

https://community.servicenow.com/community?id=community_question&sys_id=213d87a9db9cdbc01dcaf3231f96...

also check the Video

https://www.youtube.com/watch?v=19RpDrjez30

 

Please Mark Correct and Helpful

Thanks and Regards

Gaurav Shirsat

0 Helpfuls