Service Portal: Supported design for conditional visibility and mandatory variables inside Variable

[AkihiroY]

Hello Community,

We are reviewing a Service Portal catalog design and would like guidance on a recommended and supported approach for handling conditional visibility and mandatory behavior.

Current situation:
- Catalog items use Variable Sets
- Some variables inside the Variable Set are initially hidden
- Based on user input, a Catalog UI Policy with conditions is used
- UI Policy Actions are used to control variables inside the Variable Set by setting:
   - Visible = true
   - Mandatory = true

This design worked for several years without issues. However, recently we started seeing instability in Service Portal.

Symptoms:
- A JavaScript error occurs in Service Portal, such as:
  "Cannot read properties of null (reading 'mandatory')" from sp_min.js
- When this error occurs, variables inside the Variable Set are not rendered at all
- As a result, the catalog item form does not display any variables and becomes unusable for end users
- This issue does not occur for all catalog items in Service Portal;
   it only affects specific catalog items with this design pattern.

When we contacted ServiceNow Support, they confirmed that this customization pattern (using UI Policy Actions to control visibility and mandatory state of variables inside Variable Sets in Service Portal) is considered unsupported.
However, no alternative or recommended design pattern was provided.

Questions:
1. What is the recommended and supported design pattern to implement:
    - Conditional visibility
    - Conditional mandatory behavior
    for variables inside Variable Sets in Service Portal?
2. Is using Catalog Client Scripts the preferred or supported approach in this scenario?
3. Are there any known KBs, documentation, or best practices that describe this limitation?
4. For large implementations with many existing catalog items using this pattern, what refactoring strategy would you recommend to improve stability and upgrade safety?

Any guidance from architects or MVPs would be greatly appreciated.

Thank you.

[lauri457]

Seems like support will refuse to provide help with anything nowadays. UI policies are the way to go, push back with support if you want to work with them. If you want help from here you'd probably need to share more of the specifics of the variable set as I've never seen nocode ui policies throw errors

[AkihiroY]

Thanks for your input.
 

Just to provide a bit more context from our side — we’re not implying that UI Policies themselves are an issue.
We agree they’re commonly used and generally reliable.
 

In our environment, after digging into it further, the behavior seems to be tied to a very specific combination:
- Service Portal
- Variable Set variables
- UI Policies executed onLoad
- no-code mandatory and display actions
- and the evaluation order of UI Policies
 

Even though the Variable Set is only displayed later in the form,
the UI Policy with the lowest order value still appears to be evaluated on the initial page load,
before the variables are rendered in the DOM.
 

Because of that timing, the mandatory evaluation runs against variables that don’t yet exist,
which results in the sp_min.js error.
 

So from what we’re seeing, this seems to be more about evaluation timing and this particular design pattern,
rather than a general issue with UI Policies.

[lauri457]

Not saying it is not a platform issue and ui policies have seen some uplift, but I'd be curious to see your variable set and the ui policies/actions or even the stack trace for the error from the console. I couldn't find other posts on community with similar issues, if something like ui policies in variable sets were bugging out I'd assume there would be a lot more community posts.

The order on fields and ui policies should not matter or how they are rendered as the form metadata is loaded with the catalog item widget and the order column will just affect their order in the array. The object with the fields, ui policies etc. is then bound to the directive that will initialise the ui policies with an ng-init directive meaning it is run post-link and will have access to the bound object in scope. 

var $sp = new GlideSPScriptable(/*portal record sysid*/"70cd9f3b734b13001fdae9c54cf6a72f");
var catItemData = {};
catItemData.sys_id = "186d917a6fab7980575967ddbb3ee4f2" //sc_cat_item
catItemData.is_ordering = true;
//prints the form metadata for the item
gs.info(JSON.stringify($sp.getCatalogItem(catItemData), null, 2));

The ui policies themselves, atleast in the portal work just by taking a note of the variables to listen to at the initialisation phase of the form and then using the gforms private event listeners to listen to form changes and comparing it to the conditions from the ui policies array and then running actions first and then the script. 

//you can register your own callback to the 'change' event from the console
const gform = angular.element("sp-variable-layout").scope().getGlideForm()
gform.$private.events.on("change", (...args) => console.log(args))

[Ankur Bawiskar]

@AkihiroY 

I don't think simply UI policy or UI policy actions are causing this issue as they have been used widely in multiple customer and big catalog form

Looks mostly like a platform thing

From when this issue started coming?

Did you recently upgrade?