This comes up every time I train a new ServiceNow admin. Choice lists and custom tables are two different ways to deal with validated data. For those new to development / administration, validated data is simply "data you pick" vs data you type. A Description field is not validated data, but a State or Category field is.
If you've spent any time on the ServiceNow interface, you'll have seen these two interfaces....
CHOICE LISTS
CUSTOM TABLE REFERENCE
So with two ways to present validated data, which way should we pick? I've identified a few ways to help you decide.
1) Volume of Options
Small volume of choices? Choice list!
Large volume of choices? Custom table + Reference field!
You just can't get around the fact that the choice list is only good for a small number of values that can be "eyeballed". Because it has limited text search capability, scrolling will make it a royal pain in the sit-downer. A custom table + reference field is purpose built for large data sets, and has a wider range of search features. Choice lists can only be search by typing to return choices that "start with". Custom table references can be searched with an "*" to return contains.
2) Frequency of Change
Static values that change practically never? Choice list!
Frequent value additions / modifications? Custom table + reference field!
Modifying choices is an administrative function, and should be captured in update sets. This will *signficantly* slow down how quickly things can change. A custom table, however, can be delegated to non-admins to manage creation and update of data.
3) Data Simplicity
Single data element (like state... only one word)? Choice list!
Multiple data elements? Custom table + reference field!
The only thing we care about State and Priority are their names. This makes them ideal for choice lists. However, if we look at data like Location, User, or Config Item, there's tons of data we might want about each record. A user will have name, phone numbers, titles, managers, VIP status etc. If you need anything more than a name, you'll likely want a custom table + references to manage it. The real trick here is looking into the future. Many have been the time where devs have assumed a single data element, only to have people want to track 2 or 3 more properties.
UPDATE: WHAT IF EACH PARAMETER FAVORS DIFFERENT METHODS?
After some contemplation, I feel I should leave you with an order of importance. Its likely that no situation will see all three parameters align to the same answer. In that case 3 > 2 > 1.
The most important component of the decision is the data simplicity. If there's more than one element for each choice, you NEED a table, even if its a few entries that never change.
The next is frequency of change. All other things being equal, you want to offload the management of data outside the SN admin role.
4 Comments
