Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

Issue on CSM portal for restrict the filter data

veenitk
Tera Contributor

I am working on CSM portal and there is one issue that when in My list i go to filter condition so in choice list there are every field is coming but for external user i want to restrict the fields . so what are the options will service now give and what all are the possible solutions ?

 

veenitk_0-1785482497807.png

 

1 ACCEPTED SOLUTION

vaishali231
Kilo Sage

Hey @veenitk 

There are several approaches you can consider depending on your requirement.

1. Field-Level Read ACLs 

The first thing to evaluate is whether the fields should be accessible to external users at all.

If a field should never be visible to external users (for example, Assignment Group, Assigned To, Work Notes, Close Notes, or other internal fields), implementing field-level Read ACLs is the recommended OOTB approach.

Pros

Fully supported and upgrade-safe

Secures the field across the platform

Applies consistently to forms, lists, reports, REST APIs, and the portal

Cons

Hides the field everywhere, not just in the portal filter

Not suitable if the field should remain visible in other contexts

This approach is appropriate only when external users should never have access to those fields.

 

2. Customize the My Lists Widget 

If the requirement is only to limit the fields displayed in the portal filter, the recommended approach is to clone the OOTB My Lists widget (or customize the server-side logic that provides the field metadata).

Instead of returning every available field, return only a predefined whitelist based on the user's role.

For example, external users could be limited to:

Number

State

Priority

Opened

Account

Contact

Short Description

while internal users continue to see all available fields.

Pros

Affects only the portal

No impact on internal users

Flexible and easy to extend

Better customer experience

Cons

Requires widget customization

Customizations should be reviewed during upgrades

This is generally the approach I would recommend for portal-specific requirements.

 

3. Customize the Script Include / Server-Side API

In many implementations, the widget does not build the field list itself but retrieves it from a Script Include or another server-side API.

Rather than modifying the client-side code, you can intercept the metadata before it is returned and filter out unwanted fields.

Pros

Cleaner architecture

Reusable across multiple widgets if needed

Easier to maintain than client-side modifications

Cons

Requires identifying the server-side component responsible for generating the field metadata

 

4. Build a Custom Filter Experience

If the business only requires a small number of search options, another approach is to replace the generic Condition Builder with a custom filter panel.

For example, expose only:

Case Number

State

Priority

Opened Date

Account

Then generate the encoded query programmatically.

Pros

Complete control over the user experience

Simpler interface for external customers

No unnecessary fields exposed

Cons

More development effort

Replaces the standard OOTB filtering experience

 

5. Dictionary Attributes

Dictionary attributes do not provide an OOTB mechanism to control which fields appear in the Service Portal Condition Builder.

Although certain dictionary attributes affect field behavior in forms and other platform components, they do not restrict the field list displayed by the portal's filter builder.

 

6. UI Policies / Client Scripts

UI Policies are not applicable because they only affect form behavior.

Client-side DOM manipulation could technically hide fields after the dropdown is rendered, but this is not recommended because:

It is only a UI change and does not provide real security.

It is fragile and may break after upgrades.

Users can potentially bypass it.

 

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb




View solution in original post

1 REPLY 1

vaishali231
Kilo Sage

Hey @veenitk 

There are several approaches you can consider depending on your requirement.

1. Field-Level Read ACLs 

The first thing to evaluate is whether the fields should be accessible to external users at all.

If a field should never be visible to external users (for example, Assignment Group, Assigned To, Work Notes, Close Notes, or other internal fields), implementing field-level Read ACLs is the recommended OOTB approach.

Pros

Fully supported and upgrade-safe

Secures the field across the platform

Applies consistently to forms, lists, reports, REST APIs, and the portal

Cons

Hides the field everywhere, not just in the portal filter

Not suitable if the field should remain visible in other contexts

This approach is appropriate only when external users should never have access to those fields.

 

2. Customize the My Lists Widget 

If the requirement is only to limit the fields displayed in the portal filter, the recommended approach is to clone the OOTB My Lists widget (or customize the server-side logic that provides the field metadata).

Instead of returning every available field, return only a predefined whitelist based on the user's role.

For example, external users could be limited to:

Number

State

Priority

Opened

Account

Contact

Short Description

while internal users continue to see all available fields.

Pros

Affects only the portal

No impact on internal users

Flexible and easy to extend

Better customer experience

Cons

Requires widget customization

Customizations should be reviewed during upgrades

This is generally the approach I would recommend for portal-specific requirements.

 

3. Customize the Script Include / Server-Side API

In many implementations, the widget does not build the field list itself but retrieves it from a Script Include or another server-side API.

Rather than modifying the client-side code, you can intercept the metadata before it is returned and filter out unwanted fields.

Pros

Cleaner architecture

Reusable across multiple widgets if needed

Easier to maintain than client-side modifications

Cons

Requires identifying the server-side component responsible for generating the field metadata

 

4. Build a Custom Filter Experience

If the business only requires a small number of search options, another approach is to replace the generic Condition Builder with a custom filter panel.

For example, expose only:

Case Number

State

Priority

Opened Date

Account

Then generate the encoded query programmatically.

Pros

Complete control over the user experience

Simpler interface for external customers

No unnecessary fields exposed

Cons

More development effort

Replaces the standard OOTB filtering experience

 

5. Dictionary Attributes

Dictionary attributes do not provide an OOTB mechanism to control which fields appear in the Service Portal Condition Builder.

Although certain dictionary attributes affect field behavior in forms and other platform components, they do not restrict the field list displayed by the portal's filter builder.

 

6. UI Policies / Client Scripts

UI Policies are not applicable because they only affect form behavior.

Client-side DOM manipulation could technically hide fields after the dropdown is rendered, but this is not recommended because:

It is only a UI change and does not provide real security.

It is fragile and may break after upgrades.

Users can potentially bypass it.

 

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb