Decisions, decisions, decisions…

One of these days a question was asked on ServiceNow’s Slack channel about the way switch statements worked in JavaScript and ServiceNow.
One thing lead to the other and Decision Tables quickly came up as a possible solution to the problem:

I do have a requirement to assign specific requested item to specific users depending on what category they select on the form

Slackers seemed interested in the idea and wanted an article on Decision Tables, so here it is. I’ll try to make it as short and simple as possible, so one can get the greatest benefit with a minimal time investment.

As explained in the Slack thread, solving the above mentioned problem by using Decision Tables is trivial and it boils down to:

1. Creating a new record in table Decision Table, where one specifies the table providing the answers – in our case User [sys_user].
2. Define the inputs based on which the system will come to a conclusion. This can be anything that can be represented in a table field, like a reference, a number or a simple string.
3. Define the outputs, and the condition for each of those. The outputs will be records in the table specified as answer table. Each possible answer/output one defines will have a condition and the conditions will be built using the inputs defined.
4. Finally, with as much as 3 code instructions one can get the answer.

So let’s describe how one would build the solution, using mostly pictures, cause – I hear – those are worth quite a lot as opposed to words 🙂

One would create the Decision Table record specifying the table that will provide the answers:

Next the input shall be specified in this case just one, the category. For simplicity the example will be using a simple string “field”. The input is given a type (String), a label (Category) and a name (u_category).

The only thing left is to define what will be the answer under which condition. Here one will be able to make use of the input defined in the previous step. Only inputs defined can be used in the condition builder:

However the inputs can be of “complex” types like Reference or Choice so complicated conditions can be defined. But the example will stick with simplicity.

It’s easy to define a decision (as opposed to making one 🙂 ) that provides an answer: one only needs to build the condition ([Category] [is] [A]) and indicate the record to be “returned” (User: Abraham Lincoln).

To better illustrate what is going on, a second decision providing an answer shall be defined:

Just to be on the safe side, to make sure one will always get an answer, a default one will also be defined:

Now the setup is ready; if we look at the result we can see that is is like a function with a switch statement. It has a name, receives a parameter (u_category) and it has a switch block with cases that based on conditions (not visible in the list) returns one of the values – column “Answer” here:

Now one can make use of all this setup in code, by leveraging the Decision Table API. Let’s see how:

	// Declare a DecisionTableAPI instance
	var dt = new sn_dt.DecisionTableAPI();

	// Next find the answer - this will be a GlideRecord, containing a record
	// in the answer table, in our case sys_user.
	//
	// For this one needs to call function getDecision passing in two
	// parameters:
	//     1) the sys_id of our Decision Table record
	//     2) a plain object that has as keys the column names of the inputs
	//        and as values, well the value of each input
	//
	// Though in this example one input has been defined, so the map will
	// contain just one property
	var sys_user_gr = dt.getDecision('40cd3b662f7da010c6ba2ca62799b655', { 'u_category': 'A' });

	// The decision is on of the records indicated in the answers
	// Here it is just displayed, but could be used in a Business Rule or
	// WorkFlow to set the Assigned to value
	gs.debug(sys_user_gr.getDisplayValue());

As can be seen, with just two lines of code/instructions one can already have the answer. The 3rd one is using the answer. Should be noted that the answer will be a GlideRecord object on the “Answer” table, containing the record indicated “Answer” in the chosen Decision record. If no answer are correctly evaluated and no default answer has been defined, the returned value is null.

Running the code in Scripts Background prints out:

Because one of the Decision records had as condition [Category] [is] [A], the system returned the answer specified in that Decision record (User: Abraham Lincoln) – because ‘A’ has been passed in as value for input u_category.

Rewriting the code so that ‘D’ is passed in as value for input u_category, will result in answer “User: David Loo” being returned. For any other string passed in as value for input u_category, the default answer “User: Barbara Hindley” will be returned.

That would be all for now. In a future article I will modify the setup so that the input will be a reference and will re-write the conditions so that the categories will be selected in a drop-down.