Updating one RITM updates all RITM's on the REQ

jsummers
Kilo Contributor

Trying to set it up so that if someone updates a variable that is shared between RITM's (as in, shares the same name), it will update all of the variables, on all of the RITM's, of that REQ. The example would be for on-boarding where we have an Order Guide that creates the REQ using Catalog Items and variable sets. If the variable Employee Start Date (emp_start) needs to be updated, HR only has to update it on one Catalog Item and then it could replicate to all of them.

 

I'm hoping someone has already accomplished this but can't seem to find a discussion. If they haven't, would this be best through a Business Rule that would run through all of the RITM's via the REQ?

 

Any help would be greatly appreciated.

-Jon

1 ACCEPTED SOLUTION

unigrpmm
Giga Contributor

Jon --   I wrote a script yesterday that got this to work.  


Table:   sc_req_item


When:   After, Update


Condition:     current.variable_pool.changes()



updatePeerItems();


function updatePeerItems() {



var req = new GlideRecord('sc_request')  


if (req.get(current.request)){  


          req.description = current_description;  


          req.update();  


    }  




    var gr = new GlideRecord("sc_req_item");


    gr.addQuery("request", current.request);


    gr.query();


    while (gr.next()) {  


// names of common variables all start with common...


gr.variable_pool.common_LN = current.variable_pool.common_LN;


gr.variable_pool.common_MI = current.variable_pool.common_MI;


gr.variable_pool.common_FN = current.variable_pool.common_FN;


gr.variable_pool.common_preferred_name = current.variable_pool.common_preferred_name;


gr.update();


}  


}


View solution in original post

10 REPLIES 10

unigrpmm
Giga Contributor

Jon --   I wrote a script yesterday that got this to work.  


Table:   sc_req_item


When:   After, Update


Condition:     current.variable_pool.changes()



updatePeerItems();


function updatePeerItems() {



var req = new GlideRecord('sc_request')  


if (req.get(current.request)){  


          req.description = current_description;  


          req.update();  


    }  




    var gr = new GlideRecord("sc_req_item");


    gr.addQuery("request", current.request);


    gr.query();


    while (gr.next()) {  


// names of common variables all start with common...


gr.variable_pool.common_LN = current.variable_pool.common_LN;


gr.variable_pool.common_MI = current.variable_pool.common_MI;


gr.variable_pool.common_FN = current.variable_pool.common_FN;


gr.variable_pool.common_preferred_name = current.variable_pool.common_preferred_name;


gr.update();


}  


}


Miriam, would you please explain what's happening in this part of the script?


gr.variable_pool.common_LN = current.variable_pool.common_LN;
gr.variable_pool.common_MI = current.variable_pool.common_MI;
gr.variable_pool.common_FN = current.variable_pool.common_FN;
gr.variable_pool.common_preferred_name = current.variable_pool.common_preferred_name;

I'm not familiar with common_LN, common_MI, et al.   And I always enjoy a good lesson from a master!


Thank you in advance!


This is for onboarding.   I created variable sets for the common pieces of data that every RITM and task would need.     One variable set contains the new hire's last name, middle initial, first name and preferred name.   The variable set is named - "common new hire info". Its variables are common_LN, common_MI, etc. That variable set is on every RITM that launches from the order guide.   The order guide has "cascade variables" set to yes.    



The user is able to update the RITMs on the REQ with modified data until the REQ and RITMs are approved.   The user is also able to copy an REQ that was rejected so they can "fix" why it was rejected, make a modification to one of the RITMs and send it back through without keying from scratch.  



This script makes sure that whatever variable modification they make to one of the RITMs, the common variables are kept in sync (last name, first name, etc.).     This script is only needed for onboarding -- I will either have to find a way to add conditions to only do this for the common, onboarding variables OR, I'll have to only allow one item, per req for the rest of the catalog.


Miriam, Thank you for the explanation.   I wish I had "closed the loop" with you before I wrote our onboarding application.


I bet we could have benefited from your experience.


Nice work, Miriam! Works like a charm.



Now is where I get greedy, haha. I currently have 53 variables that are indeed common (very extensive form, but very effective for all of the fulfillment groups) and would like to see if there was an easier way to loop through these instead of spelling each one out. I used excel to quickly build out the very long script, but am now concerned that this is just another area that I might forget to update if we just add a single variable. Thoughts?