The list collector variable type in the service catalog is advantageous when it comes to allowing multiple selections on a catalog variable without creating a bank of checkboxes or a bunch of extra variables for users to read through, (but only if you have a table to reference to generate your options). This has been one of my pet peeves for quite some time. I finally took some time to sit down and figure out a way to make list collector variables more useful for when you want the user to be able to select multiple values but do not want the administrative overhead that can come with a whole new table every time your stakeholders want a multiple-choice, multiple selection variable.
Let’s get started:
1. On your catalog item, create a new multiple-choice or select box variable (either will work, we are after the “Choices” related list here), give it a name and some question text, and then submit.
2. Add any choices your variable needs.
3. Switch the variable type over to a list collector. You will notice that we cannot save until we give ServiceNow a table to reference, so pick Question Choice [question_choice]
4. Add a reference qualifier of “question=XXXX” where XXXX is the question’s sys_id.
5. Out of the box, ServiceNow has an ACL on the question_choice table that locks read functionality to the catalog_admin and admin roles (and others depending on which plugins and applications you have in your instance) so you will need to update that.
**Note: which role you add to allow access to read will depend on your instance and security requirements. The snc_internal and snc_external roles are good roles for a starting point. Also, check your licensing/subscription to make sure you are not opening yourself up to additional licensing fees.
6. (Optional) You may want to deactivate the “Question Choice Related List” client script or modify the if statement in the script to be if (newValue == “3” || newValue == “5” || newValue == “21”) to show the Question Choice related list on list collector variables.
7. You now have a list collector variable without having to create a whole new table.
8. (Optional) You can now consider adding variable attributes such as no_filter or glide_list to alter the variable’s appearance on the form.
This can be used to convert multiple-choice or select box variables into list collectors easily, but the real advantage to making these variables is when cleaning up catalog items with lots of checkboxes. I have seen many catalog items where there are five or more checkboxes with a “, please select one or more options” help text with an onSubmit client script doing a check to see if the user has checked the required number of checkboxes. With a single, mandatory list collector, the user can select any options they need with the added benefit of being less tedious than creating multiple checkbox variables. Remember that list collectors also look different when viewing the item in Service Portal. While the list collector is rather bulky on the regular catalog form, it is very clean when viewed in Service Portal.
There will be times that a new table is preferable for populating a list collector variable, and this should not replace creating a regular list collector backed by a table, but it is immensely helpful when cleaning up catalog items and saving you from needing to create tons of checkboxes.
If you’d like to learn even more ServiceNow tips and tricks, connect with the Covestic team at email@example.com. You can also check out another one of our ServiceNow tips and tricks blogs here.