- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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 ?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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