UI Interactions in ServiceNow Australia: A New Way to Build Reusable UI Logic
With the Australia release, ServiceNow introduces UI Interactions in UI Builder—a more reusable and event-driven approach to defining what happens when users interact with an application.
Instead of wiring UI behavior individually to pages, developers can now create an interaction once and trigger it from different events, pages, or Declarative Actions.
In simple terms: Define the behavior once → trigger it from multiple places → maintain it in one location.
What are UI Interactions?
A UI Interaction is a reusable flow of user and system actions.
An interaction can receive inputs, execute a series of steps, use conditions or branches, perform UI actions, and finally complete through an End node.
The basic flow looks like:
Input → Trigger → Start → Steps → End
According to ServiceNow, UI Interactions support configurable inputs such as String, True/False, Choice, Reference, and JSON. The interaction can then execute its configured steps sequentially, with support for branching and parallel paths.
Why UI Interactions?
Previously, implementing complex UI behavior could involve UXF Client Actions and manual event wiring on individual pages. This could make solutions harder to maintain, especially when the same behavior was required in multiple locations.
UI Interactions address this by separating the behavior from the page where it is triggered.
For example, imagine an application where clicking a button needs to:
Validate some information
Open a modal
Perform an action
Refresh the data
Navigate to another page
Instead of recreating this logic for every page, you can define it as a single UI Interaction and reuse it wherever required.
One interaction → multiple triggers → consistent behavior.
ServiceNow specifically highlights reduced duplication, centralized logic, and simpler maintenance as key benefits.
UI Interactions vs Declarative Actions
UI Interactions and Declarative Actions are related, but they serve different purposes.
Declarative Actions primarily determine where and when an action is available, such as displaying a button on a form or list.
UI Interactions define what actually happens when that action or event is triggered.
A Declarative Action can therefore act as a trigger for a UI Interaction.
Declarative Actions UI Interactions
| Defines where/when an action appears | Defines the behavior that executes |
| Commonly used for forms and lists | Can be triggered from page events or Declarative Actions |
| Provides actions such as buttons | Provides an end-to-end interaction flow |
| Can trigger a UI Interaction | Can contain UI, logic, and scripting steps |
How Can a UI Interaction Be Triggered?
Australia provides multiple entry points for running an interaction:
1. Declarative Action
Useful when you want an action such as a button on a form or list without modifying the page itself.
2. UI Builder Page Events
Interactions can also be triggered directly from page events, including events generated by buttons and components.
This makes UI behavior much more event-driven and reusable.
Three Types of UI Interactions
When creating an interaction, you can select one of three types:
Generic
Designed to work with any component.
Form
Designed for form-specific functionality such as save, validation, and scripting.
List
Designed for list-related functionality such as refreshing a list and scripting.
The UI Interaction Toolbox
The UI Interaction editor provides a toolbox containing building blocks that can be combined to create the interaction flow.
Depending on the interaction type, you can work with:
Modals and modeless dialogs
Dynamic forms
Custom components
Conditions and If/Else logic
Navigation
Form and list actions
Client and server scripts
Data-binding inputs
This gives developers a visual way to build more complex UI behavior while keeping the logic organized inside the interaction flow.
A Simple Example
Consider a Case Management workspace where an agent clicks Resolve Case.
Instead of implementing the complete behavior directly on the page, we could create a UI Interaction:
Resolve Case Button
↓
Validate Case Data
↓
If validation succeeds
↓
Update Case
↓
Refresh Case Data
↓
Show Confirmation
↓
End
The same interaction could potentially be triggered from another component or Declarative Action without rebuilding the entire flow.
This is where UI Interactions become particularly useful—the UI trigger and the underlying behavior no longer need to be tightly coupled.
What About Existing UXF Client Actions?
One of the important changes in Australia is that UI Interactions can be used instead of UXF Client Actions for scenarios where reusable UI behavior is required.
ServiceNow notes that Declarative Actions can trigger UI Interactions, and UI Interactions can encapsulate UI, logic, and scripting without requiring page ownership or page modification.
For existing implementations, this provides an opportunity to review UI logic that has been manually wired across multiple pages and determine whether it would benefit from being converted into reusable interactions.
Why This Matters
This approach can help teams:
Reduce duplicated UI logic
Centralize interaction behavior
Simplify maintenance
Reduce page-level configuration
Build more consistent user experiences
Create cleaner event-driven implementations
Final Thoughts
UI Interactions are one of the notable UI Builder enhancements in the Australia release.
They provide a cleaner separation between how an interaction is triggered and what the interaction actually does.
For developers working extensively with UI Builder, Workspaces, and Next Experience, this opens the door to building UI behavior that is more modular, reusable, and easier to maintain.
If you're upgrading to Australia, UI Interactions are definitely worth exploring—especially if your current implementation contains multiple pages with duplicated event mappings or UXF Client Actions.
Define once. Reuse everywhere.
Hope you found this article helpful!
Regards,
Iftekhar
