Self-propagating select box vs. variable set

[kim-lindgren]

This is not so much a question as a topic for discussion.

I understand that variable sets are considered best practice, but I really don't like them. There are a few cases where variable sets can work well, but there are also many cases where they don't. In theory, variable sets could be good for sharing between many different catalog items, but as soon as someone wants to change the label or the help text on for one of these items, you end up having to create a local variable anyway. In practice, variable sets are only meaningful when the following criteria are met:

1) they contain one or more variables with much data

2) the variable(s) are shared between several different catalog items

3) we know that if the variable(s) change, we want that change to be propagated to all affected items.

This brings me to the select box variable. If I have a select box with 10 different options which will be present on 3 catalog items, and these options will be changed continuously, variable sets make a whole lot of sense. But even in this case, I find that there is often a better pattern to use:

• Let catalog item 1 hold the select box with all the options.
• For catalog items 2 and 3, use a lookup select box and fetch the options from the select box on catalog item 1. The lookup select box will reference the question_choice table with a reference qualifier that looks like this: question.ref_item_option_new.cat_item={sys_id}^question={sys_id}. 

The benefit of this is that catalog item A will own the data. This is easier to maintain, because then the group/service offering that owns catalog item A will be the owner of the select box. Responsibilities become clearer this way. It is usually less clear who is the owner of a variable set, and then if you need to make a change to the select box or other variable, you don't know who to ask for permission.

Secondly, now that the select box is stored in a particular catalog item, you can use the very same catalog item to make changes to the select box. Let the selet box be a list of custom Locations and the catalog item be "Administer locations". The sole purpose of this catalog item can be to a) Create, b) Modify, or c) Remove locations in the list. Select non-itil users can then do this on their own and the changes will be propagated to all other items that use this custom Locations list.

Perhaps this is already a very well-established pattern in ServiceNow. For me at least, this has been a realization that allows end users to have more control over various custom lists, removing some of the manual work from itil users. Feel free to comment and tell me your thoughts.

[Mark Manders]

Doesn't your second point (let end users add/modify options) go against your first: have ownership over what is shown?

Variable sets are just that: sets of variables that can be added to any given catalog item that needs that information. User data is one. You need to know who requested it and maybe some other data as location and stuff. That's not going to be 'maintained' on a single catalog item.

Certain filters are a second, like the example you had. But here again: if it's needed on several items, just make it a set and if a change is needed for one item, it should be changed for just that item, if the others don't need it and it can be used for other items that need the same selection. Your variable sets should by definition not be 'owned' by catalog item owners, but by the overall owner of the process that uses the catalog items. They should decide on if it's good to make it a set or not, so you don't get changes that get in the way of others. If your group A makes a change that is not applicable for group B, group B will get a catalog item with information they can't do anything with and will need to update their own item. 

[kim-lindgren]

Thanks for weighing in! Let's see if I understand your points.

---

@Mark Manders wrote:

Doesn't your second point (let end users add/modify options) go against your first: have ownership over what is shown?

---

In my cases, we are talking about a small number of users who need lists for various subprocesses, i.e. not global Locations but something more specific to one team. So I think in these cases it makes it easier for them to manage their own data through a catalog item that they already own.

---

@Mark Manders wrote:

if it's needed on several items, just make it a set and if a change is needed for one item, it should be changed for just that item, if the others don't need it and it can be used for other items that need the same selection.

---

I don't follow you here, are you saying that something like a label or a help text on a variable set variable can be changed for one particular catalog item? Sure enough, a label could be changed through a client script but help texts don't even allow that, if I recall? If that were possible to do, it would be much better, but since the help text can't be changed for one particular item, we end up having to move back from a variable set to a variable that lives on the item. So while in theory it sounds great to have a variable set for all cases when anyone needs a Reference variable to the sys_user table, in practice it is not feasible because requesters often need very specific labels and help texts for their particular catalog items. Or am I missing something here?

[Mark Manders]

If you need specific help text or labels on for a catalog item, then it's just a variable. You are not going to solve that with variable sets, nor with a catalog item on which you are maintaining it. But looking at a 'requestor data' variable set: why would you need different labels/help texts to get the requestors name, phone number, location, etc.? Variable sets are just re-usable sets of variables. 
And if you have specific teams in need of their own variable sets, let them maintain those. It's still one set that applies to all and in that case it doesn't matter if you maintain it as a set (one record) or through an item (which I absolutely don't see the upside of). You maintain the set (and don't let end users do that, since your team is responsible) and it's available for all items the set applies to.