Allowing selected super users access to Incidents that they are not related to?

ashishsamant
Kilo Guru

Requirement: How to allow users from a particular department/team to see Incident tickets of other teams/department, without being email notified about the other dept tickets daily happenings.
Selected super users should be able to see and create reports on this other departments tickets without receiving email notifications.
Note: There is an ACL that restricts users accessing unrelated tickets, as multiple departments use ServiceNow, and require confidentiality of their tickets. The ACL says if you are not part of the caller, opened_by, Assignment group, Watchlist or worknotes list, then you are not related to a ticket and hence cannot see it.

A simple version of requirement:

  • CEO: Let us say CEO needs access to all the tickets as monthly reporting but does not want to be email notified of daily comments and status changes on this tickets. 
  • Directors: Further down the hierarchy director of multiple departments should see only their allocated departments tickets and able to select which other groups tickets they want to see. 
  • Centralized MIS Reporting Team: Team responsible to create monthly management reports, needs access to selected departments ticket, but should not receive notifications about it daily happenings.
  • This users-group relation will be managed by the support group and not leadership users themselves. I want to discuss the core functionality design with you, on how to provide such an access.

Solution (My version): ACL + Business Rule changes(Incident Query)
1. Field (req_dep): I have a field on the Incident table called 'req_dep', and all incidents are categorized under this field automatically upon submission.
2. Group: I create n number of groups, n=count of (req_dep)
3. Roles: I create and assign the same number of roles to each of this group.
Role name prefixed with 'LR' and contains same 'req_dep' text for later use in ACL condition checks
4. ACL: Create an ACL that will check if the current user has a role with the prefix 'LR' and matches the req_dep text if so allow this user access to those department tickets.
This ACL will be table wide, I meant on the ACL definition page, the table name = incident and the next field will be blank.
5. BR: Modify the 'Incident Query' Business rule, with similar logic, so all the records are shown on the native UI page consecutively

6. Note: I have a custom table inherited from Incident, and same ACL and BR will be implemented on it. The users are shown and they report on this custom table. To simplify the explanation of requirement, I am only using Incident above.

However ServiceNow allows me to show this user the new department tickets, but it messes with the existing incident access and also scrambles the list view with the security constraint messages.
I suspect the new ACL is conflicting with existing ACL, which hides group tickets that were earlier visible to the user, as he was related to them through watchlist or worknotelist.

Any suggestion? OR
Do you have a better solution than this?

1 ACCEPTED SOLUTION

ashishsamant
Kilo Guru

Hi,

I ended up creating a single role that gives access to all the tickets of the custom table that is inherited from incidentMade changes to the 1. custom table read ACL that restricts access based on user-role: added the .hasRole() condition.
2. Business rule - incident Query with hasRole condition.

This allowed me to provide access to the inherited table, yet restrict all read access on Parent incident table, as desired.

 

View solution in original post

3 REPLIES 3

Michael Fry1
Kilo Patron

Why can't you just give them the ITIL role? Directors and MIS - just create homepage/dashboard to show them what they want to see.

There is an ACL that restricts users accessing unrelated tickets, as multiple departments use ServiceNow, and require confidentiality of their tickets.

ashishsamant
Kilo Guru

Hi,

I ended up creating a single role that gives access to all the tickets of the custom table that is inherited from incidentMade changes to the 1. custom table read ACL that restricts access based on user-role: added the .hasRole() condition.
2. Business rule - incident Query with hasRole condition.

This allowed me to provide access to the inherited table, yet restrict all read access on Parent incident table, as desired.