ServiceNow ITSM UAT Checklist: What to Validate Before Go-Live

ServiceNow ITSM is where configuration becomes an operating model. A routing rule decides who sees an incident, an SLA decides when a customer or manager is warned, an approval decides whether a change can proceed, and a closure rule determines whether the organisation believes the problem is actually resolved.

That makes ITSM UAT different from checking that individual workflow steps exist. The test must prove that the right work reaches the right people, at the right time, with enough context to act and a safe path when something goes wrong.

1. Map the service journeys that matter

Begin with the services and operational events that are business-critical. Build scenarios around the work a user needs completed rather than the form fields a developer configured.

• —A high-priority incident from submission through assignment, investigation, escalation, communication, resolution, and closure.
• —A recurring or major incident that creates related tasks, stakeholder notifications, knowledge updates, and post-incident actions.
• —A problem record linked to incidents, root-cause work, known errors, workarounds, and a permanent fix.
• —A normal, emergency, and standard change through risk assessment, conflict checks, approvals, implementation, validation, and closure.
• —A service catalogue request that requires approvals, fulfilment tasks, asset or identity updates, and a clear requester outcome.

2. Test assignment, priority, and SLA behaviour

Routing and SLA defects are among the most visible ServiceNow failures because they change who is accountable and when the organisation realises a commitment is at risk. Run scenarios with the services, locations, users, categories, and urgency combinations that change the result.

• —Assignment rules for known services, unknown services, VIP users, locations, queues, and after-hours conditions.
• —Priority calculations when impact and urgency are combined, including overrides that require approval.
• —SLA start, pause, resume, breach, and completion conditions across business schedules and time zones.
• —Escalation notifications, ownership changes, group queues, absent assignees, and work transferred between teams.
• —Reopened incidents and records with prior history so the platform does not reset or hide the operational context.

3. Exercise approvals, changes, and exceptions

Approval workflows need more than a single successful approval. Test thresholds, delegation, out-of-office behaviour, group approvals, rejected requests, changed approvers, expired approvals, and requests that become urgent while waiting.

• —Standard, normal, and emergency changes with the correct risk, approval, CAB, and scheduling behaviour.
• —Approvers who are unavailable, delegated, moved to another group, or responsible for multiple approval levels.
• —Rejected, cancelled, rescheduled, and failed implementations with clear notifications and safe rollback or recovery.
• —Segregation of duties so a requester cannot silently approve their own high-risk change where policy prohibits it.

4. Validate roles, notifications, and operational evidence

Test the same scenario as the requester, service desk agent, resolver, manager, approver, and service owner. Each role should see enough information to perform its task and no more than its access model permits.

• —Confirm forms, related lists, work notes, comments, attachments, and actions are usable for each role.
• —Verify notifications reach the right people once, with the correct record context and action required.
• —Check dashboards, SLA reports, assignment queues, change calendars, and operational metrics against detailed records.
• —Make sure audit history explains who changed the record, why the state changed, and what happened after an exception.

5. Prove failure and recovery before sign-off

A service operation is ready when it can recover safely, not merely when its happy paths pass. Simulate a missing assignment, failed notification, expired approval, unavailable integration, duplicate request, and record that must be reopened.

“The ITSM test is not complete when a ticket reaches a queue. It is complete when the team can own, prioritise, resolve, explain, and recover from the work.”