- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-06-2021 07:48 AM
Received the following question and possible solution below but wanted to hear from the Community
Topic is how/when does ServiceNow use ACL's for Reporting/PA.
Question/Use Case below:
Does reporting in ServiceNow respect the ACLs on the underlying records? For example, in our old reporting tool, User A can be looking at a Bar Chart of Issue records grouped by Priority on a Dashboard and see that 5 records are “Critical”, 7 are “High”, etc. But User B could be looking at the same exact Chart/Dashboard yet it shows there are 2 “Critical's” and 10 “Highs”. This is because User A and User B have different record-level permissions and old reporting tool renders the reporting accordingly – the Users have no idea there are actually more records they don’t have access to.
FYI - Multiple companies exists on the same ServiceNow instance.
When it comes to the company level, someone at Company A has no business knowing sensitive details (e.g. number of Overdue Critical Issues; Dollar Amount of Loss Exposure; etc.) from Company B and vice versa.
Partner tells us that the ServiceNow platform reporting capability (include PA reporting) doesn’t respect the record-level ACLs like how old reporting tool does.
Possible Solution/Suggestion:
I would suggest that in each of these dashboards we add a dynamic condition to only show records that are ‘assigned’ to that user’s company. So that no matter who views the widget/report, we can trust that they are only seeing the information relevant to their specific "Company". See screenshot attachments.
Solved! Go to Solution.
- Labels:
-
Dashboard
-
Performance Analytics
-
Reporting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-06-2021 08:09 AM
Security is handled on multiple levels.
- Lists are secured with standard ACLs. This includes viewing records in Performance Analytics. Ex. viewing a list of incidents will check the ACLs on each incident.
- Aggregate reports (this included most of them that are not lists) ignore ACLs on the record level. These reports can be secured with before query business rules as well as with the report_on and report_view (table level) permissions. Ex. viewing the count of incidents.
- Performance Analytics counts are similar to aggregate reports but are secured with Breakdown Security.
- Separating out different companies is generally done with Domain Separation which is honored across Reporting and Performance Analytics (as well as most applications).
Who can view the specifics of an incident and who can see a count of incidents are very different issues and are handled with different logic. However, the logic is all configured the same way and complex logic can be made modular and reused for different cases.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-06-2021 07:50 AM
Hi,
Sorry, I didn't read through the entire post, but got to a point where I felt comfortable enough to reply, but basically...
ACLs are respected all the way through the reporting process.
If you do not have "read" rights to the data...you won't see anything. Because you won't see anything, that data won't populate the type of report you have (list, bar, etc.). Or in your case of User A and User B, yes, their view of the data would be limited to the records returned for their respective report.
(EXAMPLE😞
Meet Ray Watson....he's a user with no ITIL access...and could only see Incidents by out of box settings that he created...he hasn't done so yet. I have given him access to reporting, but that's it...here's what he sees when he tries to create a report on Incidents:
As you can see, he can't see anything right now...so this means it's respecting the platform ACLs and not returning any other records that he wouldn't normally have access to.
Even though as an ITIL user, they'd see more like so:
Now...if I create an incident, even though this report is NOT filtered...we'll only see his...incident...
Anyways, I think you get the idea.
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-06-2021 08:09 AM
Security is handled on multiple levels.
- Lists are secured with standard ACLs. This includes viewing records in Performance Analytics. Ex. viewing a list of incidents will check the ACLs on each incident.
- Aggregate reports (this included most of them that are not lists) ignore ACLs on the record level. These reports can be secured with before query business rules as well as with the report_on and report_view (table level) permissions. Ex. viewing the count of incidents.
- Performance Analytics counts are similar to aggregate reports but are secured with Breakdown Security.
- Separating out different companies is generally done with Domain Separation which is honored across Reporting and Performance Analytics (as well as most applications).
Who can view the specifics of an incident and who can see a count of incidents are very different issues and are handled with different logic. However, the logic is all configured the same way and complex logic can be made modular and reused for different cases.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2021 09:11 AM
Adam - are bar/pie are considered same as list reports with security, since they are generated from lists?
Bar, Heatmap, Horizontal bar, Line, ***List***, Pie, Pivot, Single score, Spline