You need to hide sensitive catalog items from general users or show specialized items only to specific teams. This guide walks you through both the simple role-based approach and the more flexible ACL method.
The problem with open catalog visibility
By default, catalog items show up for all users who can access the service catalog. That means everyone sees everything — from basic laptop requests to executive-level procurement items to sensitive system access requests. Business stakeholders and security teams rightfully push back when users can see (and potentially request) things they shouldn't. The people who build catalogs — platform admins and catalog managers — need straightforward ways to control visibility without rebuilding items from scratch.
How catalog visibility controls work
ServiceNow gives you two approaches: the 'Available for' role list on the catalog item itself, and Access Control Lists (ACLs) on the catalog item table. Role lists are the quick win — you pick roles, save, done. Users without those roles won't see the item in browse views or search results. ACLs are more powerful — you can write complex conditions based on user attributes, location, department, or any other field. The key difference: role lists still allow direct URL access if someone knows the item's sys_id. ACLs block everything.
Production-level access control strategy
Start with role lists for simple cases — they handle 80% of catalog visibility needs with zero scripting. Move to ACLs when you need conditions beyond role membership: geographic restrictions, dynamic department-based access, or security-sensitive items that must block all unauthorized access. Advanced implementations combine both: role lists for the obvious cases and targeted ACLs for the exceptions. The pattern that works long-term is documenting your access control strategy so other admins know which approach to use for new items.
Before you start
- •catalog_admin or admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to your catalog item
Go to Service Catalog > Catalog Definitions > Maintain Items and open the catalog item you want to restrict. If you're working with a new item, create it first and get the basic configuration working before adding access controls.
Use the list view's search box to find items quickly rather than browsing through categories.
Set the Available for roles
Scroll to the 'Available for' section and add roles to the 'Available for' related list. Click 'Edit' and select the roles that should see this item. Leave this empty if you want all authenticated users to see the item. This is your first line of defense and handles most visibility requirements.
Add broader roles first (like itil_admin) then narrow with specific roles — the item shows for users who have any of the listed roles.
Test the role-based restriction
Save the item and test with a user account that doesn't have the required roles. The item should disappear from catalog views and search results. Then test the URL bypass by copying the item's direct URL (/com.glideapp.servicecatalog_cat_item_view.do?sysparm_id=[sys_id]) and accessing it as a restricted user — you'll see the form loads anyway.
Use an incognito browser session with test credentials rather than constantly switching users.
Create an ACL for stronger control
If URL bypass is a concern, go to System Security > Access Control (ACL) and create a new ACL. Set Table to 'sc_cat_item', Operation to 'read', and Name to your specific catalog item's sys_id. This creates an item-specific read ACL instead of a table-wide rule.
Use the item's sys_id as the ACL name so other admins know which catalog item this protects.
Write the ACL condition script
In the ACL's Script field, write your access logic. For simple role checking: 'gs.hasRole('your_role_name')'. For complex conditions, reference user fields like 'gs.getUser().getDepartment() == 'IT'' or 'gs.hasRole('admin') || gs.getUser().getLocation() == 'headquarters''. Return true to grant access, false to deny.
Test complex ACL scripts in a background script first — ACL debugging is painful once deployed.
Test ACL enforcement
Save the ACL and test again with restricted users. Now the direct URL should show an access denied message instead of loading the form. Test both the catalog browse experience and direct URL access to confirm both are properly blocked.
Clear your browser cache between tests — ServiceNow caches ACL results aggressively.
Best practices
Use role lists for straightforward access control — they're easier to audit and maintain than custom ACL scripts.
Never reference specific user sys_ids in ACL conditions — they break when users are recreated or during instance refreshes.
Document complex ACL conditions in the ACL's description field so future admins understand the business logic.
Test ACL changes on sub-prod first — a broken ACL can lock out legitimate users from critical catalog items.
Prefer broader roles over narrow ones in catalog restrictions — creates fewer maintenance headaches when org structure changes.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue