- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-08-2024 01:05 AM
I am investigating using Data Filtration to limit what users can see. I want to limit visibility to specific incident categories and assignment groups. However, when I build them, the user has their own tickets filtered out. The following scenarios need to be met:
-User can see: tickets they created
-Users cannot see: tickets assigned to group A with category B
-Users can see: tickets assigned to group A with category B that they created.
I tried adding a condition caller | is not | javascript: gs.getUserID(), however it doesn't accept it (like it would in the table query builder).
TLDR: I want to build a data filtration rule that applies the data condition UNLESS the user created the ticket.
Does anyone have any suggestions? I cannot use ACLs and I have already tried using query business rules to achieve the same solution (however my query is too complex to work).
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-08-2024 01:42 AM
@Marcus Roworth : Yes, this condition javascript: gs.getUserID() is not working in Data Filtration condition section. However this can be achieved by script.
Refer this blog for more information.
https://www.linkedin.com/pulse/service-now-data-filtration-plugin-how-use-caller-me-ivan-betev
Hope it helps.
Kindly mark helpful/accepted if it helps.
Regards,
Priyanka Salunke
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-07-2024 02:18 AM
Hello @Marcus Roworth ,
could you please let me know how to open this PRB1811326, I want to share this to my leads.
regards,
Pavan.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-07-2024 06:23 AM
I don't believe we can view ServiceNow Problem records (though you may be able to ask for an update/info via a HI case).
However, the general context of the PRB was to do with conflicts between query business rules and data filtration. I created a data filtration rule which hid incidents assigned to groups with a specific type. When the group is active, the data filtration rule works as expected, when the group is inactive, the data filtration rule stops taking effect (users who do not match the security criteria can see the tickets).
My scenario was: admins or members of certain groups (e.g. "customer group one" can see incidents assigned to special groups (e.g. group type "special group"). If INC0987661 has the group "Local App Support" assigned (which is a group with the "special group" type) then only admins and members of "customer group one" should be able to see it. As soon as "Local App Support" is set inactive, non-admins/users who are not members of "customer group one" can see the ticket, even though the data filtration rule should filter it out.
Hope this helps. I believe the main focus of the PRB is to develop Data Filtration from the ground up, taking into account how query business rules could affect it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-08-2024 05:45 AM
You are correct. If there is a known issue you may be able to find the document on it, but PRB records on NowSupport are useless. They don't contain any information and are only visible if you have a case related to the problem.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark