When creating Experiences and working with UI Builder, you've most likely used screen conditions to define which page variant should be shown to the user. Page variants are different versions of a page that all share the same URL path, and screen conditions are one way to determine which page variant should be displayed.
If you haven’t worked with screen conditions in a while, there have been quite a few improvements you might have missed. With the Xanadu Store 1 release, we saw some nice UI/UX enhancements, which were already a great step forward.
But starting with the Yokohama release, things got even better. A powerful new feature now allows you to not only use page parameters in your screen conditions but also leverage a server-side script to provide data that influences which page variant is shown. This gives you far more flexibility and control, especially in complex scenarios.
But before we dive into the new capabilities, let’s take a quick step back and revisite how UI Builder looked in Washington or more precisely, with UI Builder 25.0.26.
Back in Washington, with UI Builder 25.0.26, and hopefully that's history for all of us, UI Builder offered only a simple text area for entering the screen condition of a page variant.
The condition had to be written as an encoded query string. While functional, this approach was prone to errors, especially when dealing with long or complex conditions.
And if you were on the Experience overview page and wanted to check the screen condition of a specific page variant, things didn’t get much easier.
Long conditions were displayed in a single-line text field, which meant you often had to use the vertical scroll bar to view the entire expression.
That was the past. Starting with the Xanadu Store 1 Release (UI Builder 26.1), things have improved significantly. Screen Conditions can now be created using a condition builder, at least if you're working with either only AND conditions or only OR conditions.
However, if your use case requires a combination of AND and OR logic you can’t use the condition builder and you have to enter the condition as encoded query again.
But if you managed to enter a more complex condition as encoded query the condition builder is able to display the condition so that you don’t need to use the vertical scrollbar anymore.
With the Yokohama release and UI Builder 27.1, there’s a powerful new enhancement to screen conditions that hasn’t received much attention
You’re no longer limited to just using URL parameters to define which page variant should be shown. Now, you can also base your screen conditions on data returned by a server-side script, thanks to the introduction of UX Screen Collection Condition Scripts [sys_ux_screen_type_condition_script].
These scripts allow you to evaluate any logic you need on the server side and return values that your screen condition can use. For example, your condition script could return a variable indicating if the current user is the assigned to of the record, or if a specific plugin is active, or anything else you can imagen doing with server-side scripts.
When creating your UX Screen Collection Condition Script, it’s important to note that you can create only one script per Screen Collection.
The image above shows a example of a UX Screen Collection Condition Script.
The required URL parameters of the page are passed into the function scriptedRouteConditionFunction using the params object.
This example checks if the user is the assigned to of the record and additionally if the Now Assist AI Agent plugin is activated. These information’s are stored in the corresponding variables isUserAssignedTo and isAIAgentsPluginActivated. To use these variables in the screen condition the script must return an object containing the variables as keys. In addition to that you need to enter the variables as comma-separated list in the Object Keys attribute of the UX Screen Collection Condition Script.
Now you can use these variables in your screen condition.
