ServiceNow Reporting and Dashboards: Roles, Responsibilities and RACI

Reports move decisions, so the roles around them need to answer who may ask for one, who builds and maintains it, who confirms the data behind it, who approves release and access, and who is allowed to change a figure after it has been published. This page names those roles, walks the report lifecycle decision by decision, sets out the RACI and approval workflow, and covers the signs that the responsibility model has stopped working.

Key Roles in Reporting

Report Requestor (Business Owner): identifies need for a report. Understands what data decision-makers need and when. Owns the business process and metrics. Asks for reports that support decision-making.

Data Analyst/Report Developer: designs and builds reports. Understands data sources and report tool. Translates business requirements into report queries. Optimizes report performance. Maintains reports after deployment.

Data Steward: owns data quality and consistency. Confirms data is accurate and documented. Resolves conflicts when report data does not match source system. Updates metric definitions when business changes.

Report Approver: reviews reports before deployment. Confirms report meets requirements and follows standards. Approves access and distribution. Ensures report does not include sensitive data inappropriately.

Report Administrator: manages report lifecycle. Tracks which reports exist, who uses them, when they are updated. Retires unused reports. Maintains documentation and access controls.

Report Lifecycle and Decisions

Identify need: business owner identifies that a report is needed. Decision: is this report aligned with business priorities? Does it answer a real question? Or is it nice-to-have but not essential?

Design: analyst gathers requirements and designs report. Decision: what data is needed? What are performance requirements? What access controls are needed? How will data be aggregated?

Build: analyst builds report. Decision: what data sources to query? How to transform data? How to present results clearly?

Approval: report approver reviews. Decision: does report meet requirements? Does it answer the business question? Are data sources correct? Is performance acceptable?

Deployment: report is published and made available to users. Decision: who has access? How is access granted? Are users trained on report?

Maintenance: report is monitored and updated. Decision: is report being used? Is data still accurate? Does report need updates due to business changes?

Retirement: unused reports are retired. Decision: if report has not been run for a period agreed with the owner, should it be deleted? Should it be archived for reference?

RACI Matrix for Reporting

Approval Workflow for Reports

Create a workflow for report approval. Analyst builds report and submits for approval. Approver reviews and approves or requests changes. Approval triggers deployment. Workflow tracks status and prevents unapproved reports from being deployed.

Distinguish between levels of review. Low-risk reports—read-only reports for a single team—may need only analyst review. High-risk reports—organization-wide reports used for budget decisions—should have multiple reviewers including data steward and business owner.

Data Access and Sensitivity Control

Reports often contain sensitive data—salary, personal information, or competitive information. Access controls should limit who can view reports. Use query-based row-level security if possible—show each manager only their team’s data.

Audit report access. Who is viewing sensitive reports? For high-value reports, maintain audit trail of who accessed it and when. Sensitive data requires more careful control and monitoring.

Report Maintenance and Lifecycle

Track report usage. Which reports are being run regularly? Which are never run? Reports with low usage should be considered for retirement. But be careful—some reports are run rarely but are critical for specific purposes. Check with business owner before retiring.

Update reports when business changes. If a metric definition changes, report must change. If data source changes, report must change. Assign responsibility for keeping reports current.

Review reports quarterly. Identify unused reports. Identify reports with errors or stale data. Update documentation. Remove access for users who no longer need it.

Who is allowed to change a figure after it has been published

Role charts for reporting tend to describe who builds and who reads. The question that causes trouble is different: who may change what a figure means once people are relying on it. A builder can edit a condition on a report in a few minutes. Whether that edit is a bug fix, a new business rule or a quiet redefinition is a decision, and it is rarely written down. When the change is made without that decision, the trend line shifts, nobody can explain why, and the review meeting turns into a search for the cause rather than a discussion of the service.

So the useful split is between two kinds of change. A correction brings the built report into line with a rule that was already agreed. A redefinition changes the rule itself. Corrections can be approved by the builder and checked by a peer. Redefinitions need the owner of the measure, and usually the owner of any downstream report that will move. A responsibility model that does not distinguish these two cases will either slow down every fix or let every redefinition pass unnoticed.

Decision rights for the changes that move numbers

Notice that the accountable party is singular in every row. Shared accountability sounds collaborative, but in practice each shared decision waits for everyone and is finally settled by whichever senior person happens to be present. Consultation is the place for input, and the accountable person is the one who must answer for the result.

Signs that the responsibility model has stopped working

• A figure changes between two reviews and the people in the room cannot say which rule moved.
• A dashboard has a named owner who has left the organization, and nobody has been assigned since.
• Builders make changes in the report editor that the measure owner learns about only when a reader complains.
• Access requests are approved by whoever happens to answer first, with no record of the data steward’s view.
• The scheduled export list is longer than the list of people who can say why each export exists.

A single one of these is a reason to reopen the matrix. Two or more often mean the matrix has been written and then not used, which is a more serious problem than a missing row.

When a full responsibility matrix is more than a team needs

A small team with one platform administrator and a handful of reports does not need a formal matrix with a dozen roles. A single named owner for each measure, a written list of the changes that require that owner’s approval, and a monthly look at the report inventory will cover much of the risk. The formal version becomes worthwhile when more than one team reads the same figures, when a finance or audit process depends on them, or when the people building reports sit outside the team that owns the measures. Adding structure before those conditions exist mostly adds meetings.

Follow-up questions on reporting ownership

Can the report builder also be the measure owner?

Sometimes, for a small measure used by one team. The risk is that the builder approves their own redefinitions. Where that happens, a peer should review any change to a condition or a time basis before it is published.

Who answers when a reader questions a number?

The measure owner answers the question of meaning, and the builder answers the question of how the figure was produced. Sending every query to the builder means the meaning of the measure is never settled, and the same question returns each quarter.

How often should the owners be reviewed?

Whenever a person changes role or leaves, and at least at each scheduled review of the report inventory. An owner who has moved teams is a common reason a dashboard goes unmaintained without anyone noticing.

Does a RACI replace a governance model?

No. The RACI says who decides each kind of change. The governance model says what the approval process looks like, how often it meets and what evidence it keeps. Both are needed once more than one team depends on the figures.

The common reporting and dashboards mistakes guide covers ownership failures that often come up in practice.

Related guides: ServiceNow Reporting and Dashboards: Security and Access Design and ServiceNow Reporting and Dashboards Governance Model.