Help with business rule that updates the "Requested For" field on a requested item

[Chiu]

Hi guys,

We had some help several months ago to create the following script.

(function executeRule(current, previous /*null when async*/) {

var on_behalf = current.variables.requested_for;

if(!!on_behalf){
var gr = new GlideRecord('sc_request');
gr.get(current.request);
gr.requested_for = on_behalf;
gr.update();
}

})(current, previous);

It's run on the sc_req_item table on each insert.

The intention is to take the name from the "requested_for" variable on the form, and then use this to replace the name in the "Requested For" field on the RIT record.

This generally seems to work well, but we recently found an issue if the same item is requested for a few different people, added to the cart and then submitted.

For example, if I request a laptop for Person A, add to card, then request a laptop for Person B, add to cart, and then submit the order.

This results in a "unique key violation" error message. The request is generated. The 2 RIT items are generated, but they end up being for the same person (e.g. Person A), and one of the RITs will be stuck in a "pending approval" stage.

Wondering if anyone could please advise me on the script above or things to try?

Thanks,

Chiu

[Goran WitchDoc]

I know this is in London, but want to give a heads up before customization to much. There you can have something called Multi-row variable set. In this case when ordering to many people that might be the right way to go instead.

Take a look at it here: https://docs.servicenow.com/bundle/london-it-service-management/page/product/service-catalog-managem...

//Göran

[William Busby]

In my first go at ServiceNow we were given the "requirement" to implement ordering for multiple people on one request. After nearly a year of requests had been entered we were able to document that only about 6% of requests were for multiple people and most of those only had two items. After struggling with various issues, some technical, but mostly procedural it became clear the cost of maintaining this feature far exceeded the time it would have required users to enter multiple requests and we got approval to pull it out and implement ServiceNow the way it was designed.

Also, ServiceNow has features designed in to simplify the process of ordering the same thing multiple times. There are provisions in the Service Portal to create bundles (requests for common items) which can be employed quickly and makes the need for this customization difficult to justify.

IMLTHO, the solution to your problem is to stop doing it and use the system the way it was designed to be used. But, if you really need to do this the only way to implement it is to add a 'requested_for' variable on each item. With items published from your product catalog (HW and SW items) you'll need to script this to happen when the 'publish' activity occurs. I don't have my script any longer since I dumped this approach a very long time ago but if you do some sniffing through the variables table you should be able to reverse engineer the changes needed. For the other service catalog items the people who build the item will just need to adopt the process of entering it.

[Chiu]

Thanks for the replies all, it's helped to give me some insight into things. I wasn't aware that the "Requested For" field as not unique at the sc_req_item level but this certainly explains the issue with using it for more than one person.

Much appreciated!