Disclaimer – This article is part of a series exploring the new features and capabilities introduced in the Australia release. Since we’re still in the Early Availability (EA) phase, things may change before General Availability (GA).
With the upcoming Australia Release, ServiceNow is introducing UI Interactions. If you have ever wrestled with the complexity of configuring Declarative Actions (DAs), you will want to pay attention.
A UI Interaction is a completely new entity. It is a reusable, interactive user flow combining UI, logic, and scripts that can be triggered from Declarative Actions or UI Builder events.
By simplifying the configuration process, UI Interactions make it incredibly easy to let users interact with a page without forcing you to take ownership of that page.
I recently spent some time exploring this feature. In this article I share are a few learnings, workarounds, and under-the-hood experiences I discovered along the way. In my next article I will share some examples of UI Interactions I created.
Note: This article assumes a basic understanding of UI Interactions. If you are entirely new to the concept, I highly recommend watching ServiceNow Experiences in Australia, Part 2 | Developer Passport first.
Demo Data
One of the best ways to learn a new feature is by tearing apart examples. ServiceNow also provides examples for UI Interactions. However, it took me a while to realize where to find them.
Once you updated the UI Builder after upgrading to the Australia release (or spinning up a fresh instance), UI Interactions are available. But if you open UI Builder and switch to the UI Interactions tab, the list is empty.
To view the examples, you need to manually load the demo data for the @devsnc/sn-interaction-builder plugin.
Once you do that, the sample UI Interactions will populate, giving you a great starting point.
The order of creation matters
I immediately ran into a strange problem. The order in which you add the actions to the UI Interaction flow matters.
In a fresh UI Interaction, I can directly add an if/else logic after the start node.
However, if I add a dialog to the UI Interaction flow first, I can only add a And logic between the start node and the dialog. If you realize halfway through building that your interaction needs to start with an if/else logic, you can't just add it at the start. You have to delete what you built and start over.
No Drag & Drop
Quickly after starting playing around, you will notice that you can not drag elements around like you are used to do in UI Builder or Flow Designer. That means if you have placed two elements in your flow and you want to change the order of these you need to delete one element and create it new at the place where you want to have it.
Now you may think that’s not a problem. It’s just adding the element at the new location and redo the configuration for one or two parameters. But depending on the element you need to create again this can be a lot of work. This brings us to the next point.
Custom Dialogs Can’t Be Reused (Through the UI)
When building a UI Interaction, you can create and use your own custom Modal or Modeless Dialogs. If you choose to use a Modeless Dialog, ServiceNow redirects you to the component builder to create a brand new component.
Yes, that’s right. You directly create a new component. You are not able to select a component you already created.
This means when you later notice that you need to delete the Modeless Dialog in your flow because you need it at another place in your flow, you need to create the whole component new, from scratch.
Once I realized this I wanted to see if there was a way around this limitation even if the UI doesn't provide a solution for it (yet?).
UI Interactions are stored in the sys_ui_interaction table. The key here is the steps attribute, which stores the entire flow as a JSON object. Every step of the flow is one attribute within this JSON object.
The inputs attribute for my custom Modeless Dialog contains an element called contentSysId which is the sysId of the component I have created using the component Builder.
If you add a new Modeless Dialog to your flow, you can go directly to the sys_ui_interaction record, edit the JSON, and paste the contentSysId of your original component. This allows you to reuse components across different UI Interactions without manually duplicating them.
With this working I wanted to see if I can create my own step definition to make it even simpler to reuse a component.
Creating Custom Step Definitions
Disclaimer: This is purely for the joy of exploring how the platform works under the hood. I do not recommend doing this in a production instance.
The actions available in a UI Interaction are defined in the sys_ui_interaction_step_definition table. By default, ServiceNow locks this down with a Create and a Write ACL, which is a strong hint that we aren't supposed to play with them yet.
However, for testing purposes, I created my own versions of these ACLs to grant myself access. I used the existing "Form" dialog definition as a template, copied the record, and swapped in the sys_id of my custom component.
The new definition appeared in the UI Interaction Builder and worked perfectly!
