Also Request For and subsequent variables

ray evans
Tera Guru

Hi

 

On my catalog item I have 'Requested For' and a yes/no variable (which triggers more variables via UI policy). Basically what I'm wondering is - If I 'enable also request for', can I create a copy of the yes/no variable so it needs to be answered for each person named? Or is there any other way to do this?

 

Thanks

 

Ray

1 ACCEPTED SOLUTION

If the answers to the other questions are the same for each requested for, then a list collector referencing the sys_user table will let you select multiple users.  If the answers, or the need for some of the other questions could be different for each user, then a MRVS is the way to go.  You don't need the requested for variable type - just make it a reference on sys_user.  In either approach, the workflow is where you would have a Run Script activity to split this one RITM into one for each requested for.

View solution in original post

4 REPLIES 4

Brad Bowman
Kilo Patron
Kilo Patron

Hi Ray,

It sounds like you may want to check out the multi-row variable set.  This allows you to add one or many variables that will appear in a table, so the user can add a row - for each requested for and yes/no in this case.  The advantage to this is you don't need to know how many requested for they will populate, the MRVS will handle one entry or many.  You can have a UI policy within the MRVS that controls if other variables within the MRVS are shown vs hidden, or at least editable vs read-only.  With some scripting you can also do things like show or hide certain variables on the main form based on answers in the MRVS, so if any are Yes, show these variables,...

https://docs.servicenow.com/bundle/tokyo-servicenow-platform/page/product/service-catalog-management... 

Thanks Brad, 

 

I did consider MRVS but it doesn't accept the "requested for" variable type. I also need a new RITM to be created for each person named (with the questions being asked in order to populate each RITM).

 

Ray

If the answers to the other questions are the same for each requested for, then a list collector referencing the sys_user table will let you select multiple users.  If the answers, or the need for some of the other questions could be different for each user, then a MRVS is the way to go.  You don't need the requested for variable type - just make it a reference on sys_user.  In either approach, the workflow is where you would have a Run Script activity to split this one RITM into one for each requested for.

Thanks for the advice, i'm giving this a try. Is there any way to update the quantity added to the cart based on the number of rows?