ServiceNow Platform Performance: Roles, Responsibilities and RACI

A slow page can come from a database query, a report, a business rule or a capacity ceiling, so the first question on any performance ticket is who takes it. This page names the roles, maps them to the performance lifecycle from planning to remediation, sets out the RACI for performance decisions and escalation, and covers first-hour routing by symptom, a handover procedure for use under pressure, and the decisions the grid does not settle.

Key Roles and Responsibilities

Performance Lead: owns the performance program. Sets performance targets and standards. Monitors overall system performance. Escalates problems. Accountable if performance goals are not met. Usually IT operations or infrastructure team.

Database Administrator or database-literate platform engineer: reviews slow query patterns, creates table indexes through the platform’s index tools, and raises a case with the vendor when a database-side problem needs the hosting team. Database configuration and capacity are managed by ServiceNow, not the customer. Responds to database performance issues. When a query is slow, DBA tunes it.

Application Developers: write queries, workflows, and integrations efficiently. Optimize code for performance. Test performance changes before deployment. When a new feature causes performance degradation, developers fix it.

System Administrators: configure ServiceNow—tables, views, workflows, business rules. Monitor configuration performance impact. Change configuration if it is hurting performance. When a view is slow, sysadmin optimizes it.

Operations or Help Desk: monitor system from user perspective. Report performance issues. Track performance complaints. Provide data on what is slow and who is affected. When users report slowness, support captures details.

Performance Lifecycle Roles

Planning: performance targets are set. Who decides targets? Usually performance lead with input from business leadership. Targets should be reasonable—ambitious but achievable. Documented targets guide the team.

Implementation: features are built. Developers and sysadmins build features with performance in mind. Performance considerations shape design decisions. Complex features may be simplified if performance impact is too high.

Testing: performance of new features is tested. Who tests? Development team should do initial testing. When features are integrated, operations team does full system performance testing. Performance tests should use realistic data volume.

Monitoring: production performance is monitored continuously. Who monitors? Operations team or monitoring tools. When performance degrades, monitoring alerts notify performance lead and on-call engineer.

Remediation: when performance is poor, who fixes it? DBA fixes database issues. Developers fix code issues. Sysadmins fix configuration issues. Performance lead coordinates resolution across teams.

RACI Matrix for Performance Decisions

Escalation for Performance Issues

Define thresholds for escalation. If response time exceeds its target by a small margin, escalate to the performance lead. If it exceeds the target several times over, escalate to the IT director. Clear thresholds prevent ambiguity about when to escalate.

Define response times for issues. Critical performance issues affecting many users should be addressed first. Major issues should be diagnosed promptly. Non-critical issues should be investigated within a period agreed with the platform owner.

Accountability and Trade-Offs

Performance lead is accountable for overall system performance. If performance goals are not met, performance lead is responsible for getting teams to work on it. This does not mean DBA or developers failed; it means performance lead must coordinate.

When features require performance trade-offs—new feature would make system slower—who decides? Performance lead and feature owner together. If new feature is important enough, it may proceed despite performance impact, with commitment to optimize later. Document the decision.

Continuous Improvement

Performance is an ongoing program, not a one-time project. Set annual performance goals. Measure progress quarterly. Identify performance bottlenecks. Work to eliminate them. Share performance improvements across teams so others learn.

Invest in performance tools and monitoring. Performance monitoring tools pay for themselves by enabling faster diagnosis and earlier detection of problems. Budget for performance work—do not treat it as “nice to have” when resources are spare; treat it as essential.

Document your platform performance governance in a way that’s accessible to new team members. Create a Center of Excellence or Platform Guild wiki that explains performance standards, escalation procedures, ownership of different platform layers, and the rationale behind major decisions. When new architects or platform owners join, they can refer to this documentation to understand the platform performance framework your organization has established and the trade-offs you’ve already considered.

Settling who takes a slow-page ticket before anyone opens it

Most performance tickets arrive as a complaint about a screen rather than a diagnosis. A requester writes that the change form takes half a minute to open, and the first decision has nothing to do with indexes or code. It is which role takes the ticket. A RACI grid only answers that question if the team has already agreed what counts as a performance ticket, which evidence the reporter must attach, and the point at which the work leaves the service desk. Those three agreements often settle more arguments than the grid itself, so write them down before any names go into the cells.

The failure pattern is predictable. The service desk forwards the complaint to the developer who last edited the form. The developer reads the form, finds nothing wrong with the code, and sends it back. Meanwhile the user has rebooted their browser twice and opened a second ticket. Ownership is not a courtesy in this situation. It determines whether the first person who touches the case has the access and the evidence needed to decide anything.

First-hour routing by symptom

A routing table is more useful than a general statement of responsibility, because the person on the service desk can apply it without interpreting the RACI. The table below is a starting shape. Adjust the columns to what your service desk actually records.

Notice what the table does not do. It never assigns a symptom to two owners at the same time. Copying a role is allowed, but only one name sits in the owner field. Shared ownership is a common cause of stalled cases, where two teams each assume the other is working the ticket.

A handover procedure the team can follow under pressure

When a case is handed from one role to another, the receiving owner should be able to start work without a phone call. Use the sequence below and keep each step to a single line in the ticket.

1. Confirm the slowness is reproducible for a named user or role, and record the steps that reproduce it.
2. Note whether the slowness started at a known change, a release, or an increase in data volume.
3. Assign one owner in the owner field. Copy other roles without making them owners.
4. State the single decision the owner must make next, such as tuning a specific query or confirming that a business rule is still needed.
5. Agree the next review point: when the owner returns with a finding, or with a clear reason the case cannot yet be diagnosed.
6. Close the case only after the person who raised it has retested the same steps.

Decisions the grid does not settle

A RACI describes who does the work. It does not say who may trade speed for a feature, and that is where most real disagreements happen. Two situations recur. A business owner asks for an extra related list on a busy form, and the developer has measured that the list adds a database read for every row. Or a product team installs a plugin without a platform review, and the plugin begins running work on every record save. In both cases the platform lead should not decide alone, and the feature owner should not be able to proceed by silence.

The practical answer is a short decision record. It names the measured cost, the user benefit, the owner who accepts the cost, and the date on which the cost will be checked again. A record like this turns a quiet compromise into an accountable one, and it gives the next person a reason to revisit the trade-off rather than inherit it unexamined. The guide to common platform performance mistakes covers patterns that can produce these trade-offs in the first place.

Signs the ownership model is not working

• The same ticket is reassigned repeatedly before anyone reads the attached evidence.
• Developers hear about performance only after a release, never while the feature is being designed.
• The database administrator is asked to justify application code, or the developer is asked to explain index strategy in a review.
• Nobody can say in one sentence who approves a change to a performance threshold. The governance model is the place to settle that question before it comes up in a live incident.

When two or more of these appear in the same month, the grid is probably right on paper and wrong in practice. The fix is often a routing table, not a new layer of management. Whether a given person may see performance data at all is a different matter, handled in the access design guide.

Questions teams ask once the grid exists

Can one person hold both the performance lead and the database administrator roles?

In a small team, yes, but the overlap needs a second check. Someone who tunes a query should never be the sole approver of the threshold that flagged it, since they would be grading their own work. A peer from development is often enough to provide that second view.

Who owns the cost of a new plugin that adds load?

The product owner who asked for the plugin owns the cost. The platform lead owns the measurement and the decision on whether the measurement is acceptable. The request should carry the tables it touches, the expected volume and a rollback path before installation starts.

How often should the grid be revised?

Revise it after a reorganization, after a major release, and whenever one ticket category has been reassigned repeatedly in a quarter. A review that changes nothing is still worth recording, because it shows the model was tested rather than assumed.

What belongs on the agenda of a performance review meeting?

Open tickets ordered by age and owner, the slowest transactions since the last meeting, trade-offs that are due for re-examination, and any change to a threshold. Keep decisions separate from discussion so the record shows what was agreed, and by whom.

Next step

The routing table and handover sequence above are a reasonable starting point for your own organization. For the technical side of the same cases, the troubleshooting guide shows what each owner should check first.