- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-06-2025 01:25 PM - edited ‎08-06-2025 01:27 PM
Starting this morning, several people are having issues accessing the "My Work" link in ServiceNow. This is in the Self Service application and links to the task table with a dynamic filter to show work items for the logged in user. They're receiving the "Security constraints prevent access to requested page" error. The same behavior occurs when they try to access the Task table. I did some digging and figured out it was an ACL denying access. When I grant the sn_collab_request.basic_read role, it gives them the access they need. Has anyone else run into this issue? The only thing I can think of is that I updated the Collaborative Work Management application this morning, could that have caused the issue?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
support provided us the following workaround...
Issue:
Service Management My Work Giving Users Security Constraints Message
Steps to Reproduce:
1. My Work or My Groups Work under Service Management nav module
2. Users can also attempt to view task table
Most Probable Cause:
You are most probably hitting into this PRB: PRB1915184
Solution Proposed:
The workaround is to create the property
'glide.security.enable_detailed_table_level_acl_check'
.Set property
"glide.security.enable_detailed_table_level_acl_check"
to false to skip the detailed hierarchy checks for the initial table access decision. This will check the direct table for roles and security attributes to determine initial table access. READ operations on the records/fields will remain unaffected.for now. And, our dev team internally create a problem (i.e., PRB1915184) for permanent fix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tuesday
We ran into this the other day - very difficult to troubleshoot.
Two users had 100% identical group membership and roles, they were not members of any other groups or had any additional roles. One had the error and the other didn't...
It was related to PRB1915184 and the system property fix above worked for us.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
17 hours ago
had the exact same issue, did a cache.do (flush of the cache) and the problem was gone.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
16 hours ago
Thanks Martin - I'm now wondering whether applying cache.do first might have resolved the issue for us as well.
I raised this with support, and they advised me of the PRB along with a system property fix, which I applied. However, the fix did not work immediately. They then suggested clearing the cache, and once I did that, the problem disappeared.
What was odd is that during the support call, after I had already applied the system property fix, support couldn’t reproduce the issue with the affected users I was testing with - even though I still could, and we were all on the same node. Once I cleared the cache it started working for all users...
If anyone else runs into this, and as Martin has also suggested, it may be worth clearing the cache, as part of the troubleshooting process.
The PRB is scheduled to be fixed in Q2 2026.