Workflow Automation CoE > Decision Tables > Make Decisions from JavaScript
Goal
In this Workflow Automation Center of Excellence article, you’ll learn how to use the DecisionTableAPI from anywhere in the platform where you can execute a script.
Technology and Use Case
Decision Tables allow us to extract complex logic from our business logic. These decisions can be reused in different processes, and ownership can be easily handed to a process or decision owner. Besides editing decision tables in Workflow Studio, decision tables can be exported to, edited in, and reimported from Microsoft Excel.
The default or simply most common place to make a decision on the Now Platform® is when building flows and subflows in Workflow Studio. It lets us to decide at runtime which set of actions or subflows should be executed. Any time you expect to run further logic and actions after making the decision, we recommend creating a subflow. Flows, subflows, and flow actions can also be executed from any script field with the help of a code snippet.
Note: Learn how to get started with Decision Tables in the Workflow Automation CoE.
However, sometimes you just need a simple result based on a reusable decision. This is where the DecisionTableAPI comes in handy. This API offers a broad range of functions:
- look up all available decision tables
- look up a decision table, its inputs, conditions, or results
- create/update/delete a decision table, its inputs, conditions, or results
- make a decision based on inputs and get one or all results that match
We also added the option to quickly generate a Code Snippet for a Decision Table in the Washington DC release as well.
Use Case
In this article, we will focus on the last point in this list, making a decision with the API and using the decision results in the subsequent script.
For this use case, I’m creating an email script that can be reused in different System Notifications. The decision table allows me to dynamically determine notification text as well as email properties like the reply-to or from email address.
Other use cases
The DecisionTableAPI can also be used to make decisions in:
- ACL script field
- Virtual Agent script activity
- Service Catalog Record Producer script
- Inbound email script
- Any other JavaScript field on the Now Platform®
Instructions
To implement this use case, we’ll need a couple of components. Let’s look at them one by one.
- Create a decision table
- Create an email script
- Create a notification
- Preview the notification
- Test notification from Flow Designer
Step 1: Create a decision table
From your main ServiceNow tab, search the Navigation for Workflow Studio; this will open in a new tab. Create a new decision table based on your use case requirements.
Note: Learn more about how to get started with Decision Tables in the Workflow Automation CoE or watch our latest Platform Academy session with Julia Perlis. For some hands-on experience, you can complete last year’s CreatorCon Lab on Now Learning.
For this example, I created a decision table with a reference input on a custom table, “Workflow Task”. Then I built conditions based on the Task Category and the Location reference column.
As you can see, having more than one result column is possible. The first is of the type Choice, and I defined the available options directly in the column definition. Alternatively, you can use existing choice field options from any table in your instance. The second and third columns are String type and house the email address and email alias we’ll need for our notification email script later.
The individual rows will be evaluated from top to bottom. When calling the decision table through the DecisionTableAPI, you can decide whether to stop at the first row that matches or return all rows that match. For this, we have two different functions available: “getDecision” (singular) and “getDecisions” (plural).
If you’re using the “Make a decision” flow logic in Flow Designer, you can choose between the settings “First decision that matches” and “Run all decisions that match”. For the latter, follow up with a “For Each” logic to iterate through the answer records array.
Important: Make a note of the decision table sys_id from the current URL ([Instance Name]/now/decisiondesigner/decisiontable/[sys_id]). We’ll need this in the next step. The fastest way is to use the Code Snippet for a Decision Table function and then edit the script to fit your use case from there.
Step 2: Create an email script
In our use case, we only need the first result that matches, so our email script will use that function.
To create a new email script, switch to your main ServiceNow browser tab, and from the “All” menu, navigate to System Notification > Email > Notification email Scripts. Click the “New” button. Assign a name per your naming conventions (e.g., camel case or lower case and underscores). This mail script will consist of these steps:
- Instantiate a DecisionTableAPI object
- Set the decision table input variable to the current object. Current is the table/record against which the System Notification will run. The decision table input name is prefixed with “u_”, and blank spaces are replaced with underscore characters.
- Run the “getDecision” function with the sys_id you noted previously and the inputs variable.
- Map the decision answers to new script variables. Depending on the field types, use “.getDisplayValue()”. Result column names receive the same treatment as the input name; prefix with “u_” and blank spaces are replaced with underscore characters.
- Finally, you can use the answer variables in any mail script function you need for your use case. In this example, I’m using the email address and alias to set the CC recipient of the notification. Next, I override the email subject with the catering option. And last, I add some text to the email body containing the catering info and email address. (Find examples of email scripting on Docs.)
Save the email script.
(function runMailScript( /* GlideRecord */ current, /* TemplatePrinter */ template, /* Optional EmailOutbound */ email, /* Optional GlideRecord */ email_action, /* Optional GlideRecord */ event) {
var dt = new sn_dt.DecisionTableAPI();
var inputs = new Object();
// add inputs based on your decision table inputs; input names start with u_
inputs['u_workshop_task'] = current; // replace or adjust input name
var response = dt.getDecision('ba26a169dbabe950836cdad1f3961931', inputs); // replace sys_id with your Decision table sys_id
// add/map decision result columns to variables, column names start with u_
var catering = response.result_elements.u_catering_option.getDisplayValue();
var cc_email = response.result_elements.u_email.getDisplayValue();
var cc_email_alias = response.result_elements.u_email_alias.getDisplayValue();
// use decision result for your mailscript
email.addAddress("cc", cc_email, cc_email_alias);
email.setSubject("Workshop Task " + current.number + " has been updated for catering option " + catering);
template.print("Please reach out to: "+ cc_email_alias + " " + cc_email + " to arrange for " + catering + " meals.<br />");
})(current, template, email, email_action, event);
Step 3: Create a notification
To create a new notification, open the “All” menu and navigate to System Notification > Email > Notifications. Click the “New” button and give the notification an easily recognizable name. Set the Table to the same table as your decision table input. In my example, that’s the custom table “Workshop task”.
Set “Send When” on the “When to send” tab to “Triggered” so the notification is available from the Flow Designer “Send notification” action or whichever option your use case requires.
Choose a recipient user or group on the “Who will receive” tab.
Lastly, on the “What it will contain" tab, we set the default subject for the notification and the Message HTML. We can add as many email scripts as we want to a notification with this syntax: “{mail_script:email_script_name}”.
Save the notification.
Step 4: Preview the notification
Click on the UI Action “Preview Notification” and choose a test record to confirm that the email script works correctly and that we get the decision result that we expect based on the data on the records. The subject and email body should change based on the information on the task record.
Example 1:
Location Hamburg (not USA, but Germany) and Category Offsite => Restaurant and Catering email address.
Example 2:
Location La Jolla, CA (USA) and category In Office => In house and Workplace Services email address
Step 5: Test notification from Flow
While step 4 allows us to confirm that the subject and email body changed as expected, we'll have to actually trigger the email to see if setting the CC email worked. To do this, I’ve created a simple subflow with an input of the custom table “Workshop Task” and one flow action “Send notification” in which I chose the notification created in step 3 and the Workflow Task input record.
I’ll run the flow against my test record with the Test option from the flow. Once the flow execution is complete, I can check the created email record by navigating to “System Mailboxes > Outbound > Outbox”. The “Copied” field is not part of the standard form or list view, so you may have to personalize or configure the list or form view to see it and confirm the email address.
Further Considerations
Just like using decisions from flows, you may want to get all decision rows for which the condition is true when making a decision from a script. In this case, you can use getDecisions() instead and receive an array of results through which you can iterate in the subsequent logic. An example could look like this:
var dt = new sn_dt.DecisionTableAPI();
var input = new Object();
input['u_age'] = 25; //adjust input name as applicable
var response = dt.getDecisions('5b06ce5db701230034d1da23ee11a965', input); //replace with your decision table sys_id
var firstRecord = response[0];
var user = firstRecord.result_elements.u_user; //adjust result column name as applicable
Conclusion
Notification email scripts are just one of many options to use Decision Tables through the API, but one that you’d not think of immediately. I hope this example and the other mentioned use cases encourage you to think of decision tables whenever you need to make decisions that would otherwise require you to script complex if-then-else or case-switch logic. By decoupling the decision from your script or flow, you can transfer decision ownership to a process owner who may not necessarily be a developer.
