- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2022 10:04 AM
I have a requirement to add an index column/variable to a pre-existing MRVS (multi-row variable set) in a service catalog item.
I've got the catalog client script figured out to calculate the index value as 'on submit' and it works fine. the problem is- our fulfiller's have the ability to remove rows and add new ones during fulfillment. i need my index column to re-calculate and populate. I'm anticipating i'll need an additional client script for on-change, but can't seem to get started..... Here's my on-submit script below.
Any help would be appreciated!
Solved! Go to Solution.
- Labels:
-
Request Management
-
Service Desk

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2022 01:31 PM
Unfortunately there isn't an out of the box event that you could tap into that would trigger a script on a RITM or TASK when lines are added or removed from an MRVS to update another field on the catalog item.
I have done a few things where, as a value in a row is entered or changed you update a field on the form (using an onchange in the MRVS and some trickery, which you could instead employ as an onsubmit) and then, in theory, run the same script you have not, just onchange of a different field where you set the value onsubmit of the MRVS). That would only get you half-way there however.
I can't think of anything short of some very intrusive DOM manipulation that would let you take action and update an external field when a row is removed from a MRVS. It would probably require more effort to develop and maintain than benefit.
Maybe add a checkbox or something called recalculate to the form before or after the MRVS, hide it until you are on a catalog item or task, and then when the box is ticked (has a value of true) run your script to set the value, then at the end untick the box? It's not ideal, but sometimes you have to rely on Workflow Engine Mark I - human behavior - to get the job done.
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!
Michael D. Jones
Proud member of the GlideFast Consulting Team!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2022 01:31 PM
Unfortunately there isn't an out of the box event that you could tap into that would trigger a script on a RITM or TASK when lines are added or removed from an MRVS to update another field on the catalog item.
I have done a few things where, as a value in a row is entered or changed you update a field on the form (using an onchange in the MRVS and some trickery, which you could instead employ as an onsubmit) and then, in theory, run the same script you have not, just onchange of a different field where you set the value onsubmit of the MRVS). That would only get you half-way there however.
I can't think of anything short of some very intrusive DOM manipulation that would let you take action and update an external field when a row is removed from a MRVS. It would probably require more effort to develop and maintain than benefit.
Maybe add a checkbox or something called recalculate to the form before or after the MRVS, hide it until you are on a catalog item or task, and then when the box is ticked (has a value of true) run your script to set the value, then at the end untick the box? It's not ideal, but sometimes you have to rely on Workflow Engine Mark I - human behavior - to get the job done.
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!
Michael D. Jones
Proud member of the GlideFast Consulting Team!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2022 01:39 PM
I *think* you may have misunderstood my question- hoping it changes the answer....
i'm not updating a value outside the MRVS. when they add or remove rows from the MRVS, I want the index column inside the MRVS to recalculate itself, just like it does during onSubmit now. Does that make it more possible?
They still have to 'save' or update the main ticket after the add/remove action, if that helps.
If not- thanks.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2022 02:26 PM
I see, I did misunderstand slightly (you are modifying the JSON of the MRVS OnSubmit directly, not an external field) but that being the case, if you have your script set to execute on items and tasks, does it not recalculate when they save / update? The script should execute (a simple alert works on submission, then again on update / save for the RITM or TASK)
If that is not the case, then you might check the console for errors.
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!
Michael D. Jones
Proud member of the GlideFast Consulting Team!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-02-2022 04:30 PM
FYI- I ended up with a HI portal case to get help- and they ended up just switching me to an onLoad, with this explanation:
"In this situation - I believe you are running into a race condition between when submission finishes and when your g_form.setValue actually runs - in the platform, submission finishes before setValue, resulting in the behavior you've observed. Have you considered changing around the load order of your client script? I changed it to an onLoad client script instead and as far as I can tell your previous functionality is still in place"
It does handle the recalculation just fine, but if I have the 'applies in service portal' option checked, it triggers a 'javascript error in browser console' while submitting the item in the portal. That's not important in this case, so i'll just turn that off.