ServiceNow Reporting and Dashboards: Security and Access Design

Reporting and dashboard security controls which users can see which metrics, because dashboards can expose incident data, project delays and performance reviews. The page sets out analyst, manager, executive and auditor roles, least-privilege dashboard design, row-level filters and monitoring of report usage.

Role Model for Reporting Access

Reporting access must be controlled because dashboards show sensitive information: incident metrics, project delays, team performance, customer complaints. Different roles need different data visibility. An IT director should see infrastructure health metrics; a developer should see only application-specific incidents, not HR data. Service desk agents should see team statistics for their queue but not competitor analysis or pricing information.

Define roles for reporting access: analysts (can create and modify reports), managers (can view reports for their team), executives (can view organization-wide dashboards), and auditors (can view security-related reports). Assign users based on their responsibilities and information needs.

A data steward should own information governance: deciding which data is sensitive and who can see it. Without data stewardship, dashboards often expose information that should be restricted (payroll data, performance reviews, confidential projects).

Least Privilege in Dashboard and Report Design

Apply least privilege to dashboard content. A service desk team should see their queue statistics (time to resolve, abandonment rate) but should not see other teams’ data. A project manager should see their project’s timeline and risks but should not see competitor projects or strategic initiatives not relevant to their work. Use dashboard filters and row-level security to restrict data visibility.

Some dashboards are role-specific. An HR dashboard should be visible only to HR staff and their manager. A financial dashboard should be visible only to finance. Do not create one-size-fits-all dashboards that expose information to inappropriate audiences.

Sensitive metrics (salary information, retention rates, cost per employee) should be visible only to authorized personnel. Restrict access to these dashboards and audit who views them. Some organizations limit sensitive dashboard access to specific times or locations (office only, not remote).

Segregation of Duties in Report Development

Separate the roles of: report author (creates reports and dashboards), reviewer (validates accuracy and appropriateness), approver (approves report release), and owner (responsible for keeping report current). A report author might create an incorrect calculation that makes a team look bad. A reviewer catches this. An approver verifies the report serves a legitimate business purpose before publishing. An owner ensures the report data stays current.

Report development workflows should route to reviewers before publishing. Spot-check report accuracy: verify that calculations match expectations, that filters work correctly, and that the report is not accidentally exposing sensitive data. A review step catches mistakes before reports mislead decision-makers.

Audit Evidence and Dashboard Governance

Configure ServiceNow to log who created each report, when, and who accessed it. Long-lived reports should show their change history. If an important report is modified, who changed it and why? Audit trails document report lifecycle and help identify unauthorized modifications.

Track dashboard and report access for sensitive dashboards. Who viewed the salary report? When? From where? This access log demonstrates who had access to sensitive information and helps detect unauthorized access.

Establish review cycles for reports and dashboards. Quarterly review should verify: reports are still accurate (data sources have not changed), security filters are still appropriate (access control matches business needs), and owners are actively maintaining reports (removing obsolete reports, updating outdated ones).

Technical Implementation of Access Control

Use ServiceNow’s dashboard and report security features: record-level access control (show different data to different users), field-level security (hide sensitive columns), and table-level permissions (prevent access to entire tables). Configure filters so each user sees only data relevant to their role.

Test access control thoroughly. Log in as different user roles and verify each user sees only appropriate data. Common mistakes include: filters that are not applied correctly (users see more data than intended), or insufficient filters (users see data they should not access).

Consider creating role-specific dashboard copies. Instead of one dashboard with complex filters, create three versions: one for executives (organization-wide view), one for managers (team view), one for individual contributors (personal view). Multiple versions may be easier to understand than one complex dashboard with many filters.

Sensitive Data and Compliance

Identify which reports contain sensitive data: payroll, performance ratings, HR actions, confidential projects. Restrict these reports to authorized users and audit access. Some organizations require multi-factor authentication to access sensitive dashboards or only allow access from corporate networks, not remote locations.

Retention policies for reports: should reports be archived after one year? Deleted after two years? Retained indefinitely? Define retention based on business needs and compliance requirements. Do not retain sensitive reports longer than necessary.

Monitoring Report and Dashboard Usage

Monitor which reports are actively used and which are abandoned. Unused reports should be reviewed: do they serve a purpose, or should they be archived? Regular cleanup prevents report proliferation and reduces confusion.

Track access patterns for sensitive dashboards. If usage suddenly increases (many users accessing a dashboard that normally sees light traffic), investigate whether access control is working correctly or if unauthorized access is occurring.

Deciding which layer enforces each restriction

Reporting access can be restricted in several places, and a common mistake is to rely on one of them and assume the others follow. A dashboard can be hidden from a homepage, which stops people finding it but does nothing to stop someone who has its address. A report can be shared with a group, which is a sharing decision, while the underlying table can still expose the same fields through another report that nobody has reviewed. The protection a reader gets is the one enforced at the lowest layer that the figure passes through, so the design question is where that lowest layer sits for each sensitive measure.

For many instances the practical order is the underlying table access rules, then any data filtering that applies to the records themselves, then the sharing of the report or dashboard, and finally the placement of the view on a homepage or navigation list. Each layer can be correct on its own and still leak when combined. A manager who can see a team’s records through a table rule may be able to build a report that reproduces a figure the team’s own lead was never meant to share.

A decision table for where to restrict a figure

An ordered approach to testing access before launch

1. List the personas the view must serve and the personas it must exclude. Include former members of a team, contractors and people with elevated roles for other reasons.
2. For each persona, write the figures they should see and the figures they must not see, at record, summary and export level.
3. Run each view as each persona, using a test account rather than an administrator’s own session. Administrators see more than anyone else and will hide the problem.
4. Repeat the check for exports, scheduled deliveries and any embedded view, since each is a separate path to the same data.
5. Record the results as screenshots or query outputs filed with the change, giving an auditor a record of what was tested and when.
6. Repeat the test after any change to roles, group membership or the underlying table rules, because a passing result is only valid for the configuration it was run against.

When a blank dashboard is an access problem

A user who reports an empty dashboard is often experiencing an access rule working as designed, not a fault. The usual sequence is that the widget’s data source is filtered by the user’s role, the user has no matching records, and the widget renders nothing rather than an error. Before anyone changes a rule, check the user’s roles against the rules the widget relies on, and compare with a colleague in the same position who sees the data. Widening access to resolve the complaint without that comparison is how restrictions get removed by accident.

Follow-up questions on reporting access

Should reporting access follow the same model as the platform’s record access?

It should align with it, but it is not the same. Reporting exposes aggregates that a record-level rule does not anticipate, so a view needs its own review even when the records behind it are restricted correctly.

Is it enough to restrict a dashboard by its sharing settings?

Only for the dashboard itself. Any report or data source the dashboard draws on still needs its own check, and so does any other view that uses the same fields.

How should a departing user’s reporting access be handled?

Remove the access through the same process used for other platform roles, and also review the reports and schedules the person owned. Ownership of a scheduled export that continues after someone leaves is a frequent source of unexpected data flows.

Does an audit need the test results, or only the configuration?

Both. The configuration shows what was intended, and the test results show what a person actually saw. An auditor who asks for evidence of restriction often wants the second.

The platform-wide access guidance page sets out the platform-wide rules that these reporting restrictions depend on. The testing and acceptance checklist shows where the persona tests fit in a release. For a view that depends on identity data from another system, the identity integration boundaries article is worth reading first.