Built something you're proud of? Tell the story. A quick G2 review of App Engine or Build Agent helps other developers see what's possible on ServiceNow. Share your experience.

Fiield showing up in HR Agent Workspace despite UI Policy setting visibility to false

vascosoares
Tera Contributor

Hello community,

 

I was working on a form and noticed that, despite having a Catalog UI Policy applied to target record that aims to make a certain field invisible, the field is not visible in the client facing view, but still pulls through on the HR Agent view.

 

I checked for additional policies that might be making it visible and found nothing.

 

Through my research I found information saying the defined Catalog UI Policy should be enough while other sources tell me the Catalog UI Policy is not applicable on the HR Agent view despite the "Applies to Target Record" being checked.

I had a similar problem and found success inchecking the "Hidden" field on the variable record, however I don't understand why the Catalog UI Policy isn't enough.

Any explanation? Is the Catalog UI Policy applicable? Is this a matter of some other element having priority over the policy?

 

Thanks in advance.

1 ACCEPTED SOLUTION

Naveen20
ServiceNow Employee

Agent Workspace runs on Now Experience, which uses a declarative, component-based architecture. Catalog UI Policies were built for the classic/portal form engine where they execute as client-side scripts against g_form. Workspace components simply don't invoke that policy engine — there's nothing listening for those policies during rendering.

Intentional design choice, not a bug. ServiceNow chose not to port the legacy policy engine into the new framework. Instead, they're building workspace-native equivalents (Workspace UI Policies, UX Form Policies) incrementally across releases. Variable-level attributes like "Hidden" work everywhere because they're read as metadata, not executed as scripts 

View solution in original post

4 REPLIES 4

Naveen20
ServiceNow Employee

The core issue: different rendering engines

The client-facing portal (Service Portal) and the HR Agent Workspace (built on Now Experience/UI Builder) use fundamentally different rendering engines. Catalog UI Policies were designed for and execute within the classic catalog form rendering pipeline — Service Portal, the classic UI, and the standard catalog item views. They work by injecting client-side logic that manipulates the DOM at render time.

Agent Workspace, including the HR Agent view, uses the Now Experience framework, which has its own component-based rendering. It does not fully execute traditional Catalog UI Policies in the same way. The "Applies to Target Record" checkbox tells the platform to apply the policy when variables are shown on the target record (like an HR Case), but this still depends on the consuming interface actually honoring that policy execution model — and Agent Workspace either ignores it or only partially supports it.

Why the "Hidden" attribute on the variable works everywhere

When you check "Hidden" directly on the variable record (the hidden field on item_option_new), you're setting a server-side metadata property on the variable definition itself. Every rendering engine — classic, portal, workspace — reads this attribute when deciding what to display. It's not a client-side policy that gets "executed"; it's a declarative property that's part of the variable's schema. That's why it works universally.

vascosoares
Tera Contributor

Great insight! Are the factors that lead to HR Agent Workspace ignoring or partially supporting the execution known? 

Naveen20
ServiceNow Employee

Agent Workspace runs on Now Experience, which uses a declarative, component-based architecture. Catalog UI Policies were built for the classic/portal form engine where they execute as client-side scripts against g_form. Workspace components simply don't invoke that policy engine — there's nothing listening for those policies during rendering.

Intentional design choice, not a bug. ServiceNow chose not to port the legacy policy engine into the new framework. Instead, they're building workspace-native equivalents (Workspace UI Policies, UX Form Policies) incrementally across releases. Variable-level attributes like "Hidden" work everywhere because they're read as metadata, not executed as scripts 

Very nice! Thanks!