Trigger Workflow Based on Catalog Item Selection in Order Guide

jmiskey
Kilo Sage

I have kind of a tricky situation which I am trying to figure out how to approach.

We have an Order Guide with three Catalog Items to choose from.  The Order Guide itself does not have a workflow attached to it.  2 of the 3 Catalog Items in my Order Guide do.  They are pretty straight forward, creating a single RITM, so those Workflows run off of sc_req_item and are available to be selected from the Workflow field on the Catalog Item.

However, my third one is a bit trickier.  It needs to create multiple RITMs, so the Workflow needs to run against sc_request so we can create multiple RITMs within that workflow.  However, when we create a workflow based on sc_request, it is not available to be selected from the Workflow field on the Catalog Item.  

I see from Workflow -> Properties -> Conditions, I could try to set a condition of which the workflow should run.  We have done this before, based on the Order Guide value.  However, that Order Guide was pretty straight forward and didn't have three different Catalog Items, each with their own workflow, listed underneath it.  So the Order Guide field,in and of itself, does not contain enough information regarding when the workflow should be called.  It is dependent upon the Catalog Item selected in the Order Guide (have a variable for that selection).

So, how can I do this?  How can I set up the Workflow for this third option to run off of sc_request and get it to be called when that third option is selected?

Thanks

1 ACCEPTED SOLUTION

This is what I have used to trigger new items from an initial item and added to the same request.

var reqHelper = new GlideappCalculationHelper();
reqHelper.addItemToExistingRequest(current.request,<sysID of the item>, 1); // 1 is the qty
reqHelper.rebalanceRequest(current.request);

My use case:

We had an item that collected multiple share file locations, but needed individual approvals for each location.  My setup was an initial item that runs a script with this code in it to generate the individual items under the same REQ.  The original item closes automatically after the fact, so one 'item' spawns x number of individual items (dependent upon how many share file locations they request), all on the same REQ.

 

https://developer.servicenow.com/app.do#!/api_doc?v=jakarta&id=GlideappCalcHelperAPI

View solution in original post

35 REPLIES 35

Here is my code inside a workflow activity (in the dummy item):

(function(){
	
	var reqHelper = new GlideappCalculationHelper();
	var shares = current.variables.server_ro.toString();
	var sharesWrite = current.variables.server_rw.toString();
	var shareArray = shares.split(',');
	var shareArrayRW = sharesWrite.split(',');
	
	var combinedArray = shareArray.concat(shareArrayRW);
	var count = combinedArray.length;
	
	for (var i=0; i < combinedArray.length; i++) {
		// add each file selected as a separate item to current request
		reqHelper.addItemToExistingRequest(current.request, '2b7165571303c380668f56022244b050', 1); // 1 is the qty
	}
	reqHelper.rebalanceRequest(current.request);
		
})();

I have two different list collector variables that I combine to create a merged array that I loop though using that helper app to add an item for each entry in either variable.

I use two separate activities to add the needed variables to each item, one of read only and one for the read/write ones. 

Maybe go simple and try the GlideappCalculationHelper() inside a fix script just bare bones and only creating the new item in the indicated REQ.

Something like 

var reqHelper = new GlideappCalculationHelper();
reqHelper.addItemToExisitingRequest('<sys id of a known REQ for testing>', '<sys id of a known catalog item>', 1);
reqHelper.rebalanceRequest('<sys id of the REQ above>');

At least you could confirm it works or not in your instance and go from there.

I tried it, and unfortunately it did not seem to work.

Here is the code I tried.  It did not return any errors, but it did not create any new RITMs.

//capture key fields from original ritm
var orig_sys_id = current.sys_id;
var orig_req = current.request;
var orig_ritm = current.number;
var orig_submitter = current.opened_by;
var orig_bene = current.u_beneficiary;
var orig_short_des = current.short_description;
var orig_cat_item = current.cat_item;
var orig_due_date = current.due_date;

//capture key fields off of catalog item
var applications = current.variables.facets_applications_role_needs_access_to;  //list collector

//split applications list collector
var ind_app = applications.toString().split(',');

//loop through each application and create a new ritm
for(var i = 0; i < ind_app.length; i++){ 
	var app = ind_app[i];

	//get facets application name
	var app_name= '';
	var a = new GlideRecord('u_facets_application_owners');
	a.addQuery('sys_id', app);
	a.query();

	while (a.next()) {
		app_name = a.u_application;
	}

	var reqHelper = new GlideappCalculationHelper();
	reqHelper.addItemToExisitingRequest(orig_req, '197ced5fdba5234080e972ec0f9619b7', 1);
	reqHelper.rebalanceRequest(orig_req);

}

Any ideas of what I may be doing wrong there?

I was just looking at that function's documentation and realized that the quantity should be a string.

Maybe put the 1 as '1' might allow it to work??

I even double checked my run script in the workflow, and I do not have the 1 as a string, so not sure why it is actually working.  But I was trying this in a fix script in my personal instance and it was not working until I changed the 1 to a string.

 

Unfortunately, that did not seem to work.

Can you try using this in a fix script in sub prod instance?

var catItemId = "04b7e94b4f7b4200086eeed18110c7fd";
var requestId = "6eed229047801200e0ef563dbb9a71c2";
var helper = new GlideappCalculationHelper()
helper.addItemToExistingRequest(requestId, catItemId, "1");

Just change the catItemId and requestId to something found in your sub prod instance and just see if it works?  You'd then just check the REQ you selected the sys ID for and check to see if it had an additional item added.

If not, I would think you would have a HI ticket case in my opinion as that is a documented method.