Reference variable in Service Portal not working following the May 2025 platform security update
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10 hours ago
Have you ever created a catalog item with a reference variable pointing to a custom scoped table, only to find it doesn't show any results in the Service Portal for end-users? You've checked the standard read ACLs and the Application Access settings, and everything looks correct. The variable even works fine as an admin.
This is a common issue, especially following the May 2025 platform security update, which introduced stricter enforcement for query-level ACLs. Standard read ACLs are no longer sufficient for complex search functionality. So what's the solution ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10 hours ago
The problem
A Lookup Select Box variable might work correctly, but the Reference variable fails. This is the key clue.
- Lookup Select Box uses a simpler query mechanism that is typically covered by standard read ACLs.
- Reference variables in the Service Portal, however, use more complex, AJAX-based lookups and advanced search operations (CONTAINS, STARTSWITH) that are now governed by the newer query_range and query_match ACLs.
Without the correct ACLs for both read and query operations, the platform blocks the request, and the reference variable returns "No matches found" or remains empty.
The complete solution: Create all necessary ACLs
To resolve this, you must create a total of four ACLs to explicitly allow read and query operations.
Steps to create the ACLs:
- Elevate your role to security_admin. This is a mandatory step for modifying ACLs. Click your user name in the top-right corner, select Elevate Roles, choose security_admin, and click OK.
- Navigate to Access Control (ACL). In the Filter Navigator, type Access Control (ACL) and select the list from System Security.
- Create the table-level read ACL (table.None). This grants read access to the records (the rows) themselves.
- Click New to create a new ACL.
- Type: record
- Operation: read
- Name: Select your custom scoped table (e.g., x_your_scope_table_name). Leave the Field as --None--.
- On the Requires role tab, add the role(s) assigned to your Service Portal users (e.g., sn_request_read or a custom role).
- Click Submit.
- Create the field-level read ACL (table.*). This grants read access to all fields on the record.
- Click New again.
- Type: record
- Operation: read
- Name: Select your custom scoped table, and for Field, select * (All fields).
- On the Requires role tab, add the role(s) assigned to your Service Portal users.
- Click Submit.
- Create the query_range ACL. This will enable partial and wildcard searches performed by the reference variable's lookup.
- Click New again.
- Type: record
- Operation: query_range
- Name: Select your custom scoped table, followed by a wildcard .* (e.g., x_your_scope_table_name.*).
- On the Requires role tab, add the role(s) assigned to your Service Portal users.
- Click Submit.
- Create the query_match ACL. This will cover exact search queries and ensure robust query functionality.
- Click New again.
- Type: record
- Operation: query_match
- Name: Select your custom scoped table, followed by a wildcard .* (e.g., x_your_scope_table_name.*).
- On the Requires role tab, add the role(s) assigned to your Service Portal users.
- Click Submit.
- Test the variable: After creating all four ACLs, test the reference variable in the Service Portal as the affected end-user. The reference lookup should now function as expected.
Additional troubleshooting tips
- Confirm table permissions: Double-check that your table's Application Access settings have Can read enabled and Accessible from set to All application scopes.
- Verify the display field: Ensure the user has read access to the field that is set as the display value on the custom table.
- Use the Debug Security tool: If the issue persists, use the Debug Security tool (enabled as a security_admin) to get a detailed log of every ACL check and see exactly which one is failing.
By creating these necessary read, query_match, and query_range ACLs, you are explicitly granting end-users the required permissions to both view records and perform the necessary query operations to resolve the Service Portal reference variable issue.