Direct navigation: 11/12 documented All > ... paths linked to this ServiceNow instance.

ITSM — Professional Implementation from Scratch to Production

Release baseline: ServiceNow Australia (current GA · Sep 2026)
Audience: Professional Implementers · Platform Admins · Developers · Product Owners · Test Leads
Instance token: {BASE} = https://YOUR_INSTANCE.service-now.com
Related module encyclopedia: ../ITSM.md
All implementation guides: INDEX.md

0. Outcome and guardrails

IT Service Management: Restore service, remove root causes, control changes, fulfil requests, and reuse knowledge.

• Confirm product entitlement before plugin activation.
• Build and test in sub-production/PDI; never activate major plugins first in production.
• Prefer out-of-box process/configuration before custom scripts.
• Use Flow Designer for new automation; maintain legacy Workflow only when required.
• Protect data with roles, ACLs, groups, criteria, and persona-based tests.
• Australia is the deployment baseline; Brazil preview/EA is not the production baseline unless your organization explicitly validates it.

1. End-to-end operating model

Discover → Design → Configure → Integrate → Secure → Test → Deploy → Operate → Improve

Module lifecycle: Incident → Major Incident when impact requires → Problem / Known Error → Change → Knowledge; Catalog request → RITM → task → fulfilment

2. Discovery workshops and scope

Run these workshops before configuration:

3. Licensing, plugins, and release readiness

Expected products/plugins: ITSM core; Change Management; Problem Management; Service Operations Workspace; Performance Analytics (licensed/optional)

1. Open Plugins.
2. Confirm entitlement with ServiceNow account/product owner.
3. Activate in a non-production instance.
4. Review activation logs and newly created roles/modules.
5. Capture configuration in a named Update Set where supported.
6. Confirm Australia release/build at System Stats.

4. Roles, groups, and security model

Typical roles: itil, itil_admin, incident_manager, problem_manager, change_manager, knowledge_admin, catalog_admin

Professional rules:

• Roles → Groups → Users; avoid direct role grants.
• Separate admin/configurer, manager, fulfiller/agent, requester, auditor, and integration personas.
• Test table, row, and field access with impersonation.
• Never treat UI visibility as security; enforce ACL/criteria.
• Record privileged access and quarterly access review.

5. Foundation configuration sequence

1. Create reference data and ownership groups.
2. Configure states/models/templates before automation.
3. Configure assignment/routing and schedules.
4. Configure SLAs/entitlements where applicable.
5. Configure notifications and knowledge.
6. Configure workspace/portal/mobile experience.
7. Configure integrations and system properties.
8. Build reports and dashboards.
9. Build ATF and UAT packs.
10. Complete deployment/rollback runbook.

6. All component pages and direct URLs

Enter your instance once in the HTML header; every {BASE} link then opens the correct page in that instance.

7. Module configuration tutorial

1. Open each component in the order shown in §6.
2. Create minimum viable reference data and one happy-path record.
3. Configure state transitions, assignment, approvals, notifications, and SLAs.
4. Validate agent and requester experiences using different personas.
5. Add exception paths: rejection, reassignment, cancellation, timeout, integration failure.
6. Keep customization decisions in an OOTB-vs-config-vs-custom register.

7.1 Complete settings and configuration control matrix

Use this as the minimum configuration workbook. Add product-specific rows discovered during workshops; do not leave a changed setting without an owner and test.

Configuration rule for ITSM: record OOTB default, approved value, owner, rationale, environment, transport method, and test case for every changed setting.

7.2 Component-by-component hands-on labs

Complete every lab below in a non-production instance. These labs cover every module-specific page listed in §6.

Component Lab 1 — Incidents

Purpose: Restore normal service
Navigator: All > Incident > All — Open direct
Direct: Open Incidents

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-01 where the component supports records.
4. Configure form/view, states, mandatory fields, assignment, priority, SLA, closure, and reopen rules.
5. Test happy path plus reject/cancel/reassign/escalate/timeout/reopen.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 2 — Create Incident

Purpose: Create a controlled test record
Navigator: All > Incident > Create New — Open direct
Direct: Open Create Incident

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-02 where the component supports records.
4. Configure form/view, states, mandatory fields, assignment, priority, SLA, closure, and reopen rules.
5. Test happy path plus reject/cancel/reassign/escalate/timeout/reopen.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 3 — Problems

Purpose: Root-cause management
Navigator: All > Problem > All — Open direct
Direct: Open Problems

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-03 where the component supports records.
4. Configure form/view, states, mandatory fields, assignment, priority, SLA, closure, and reopen rules.
5. Test happy path plus reject/cancel/reassign/escalate/timeout/reopen.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 4 — Known Errors

Purpose: Document workaround and root cause
Navigator: All > Problem > Known Errors — Open direct
Direct: Open Known Errors

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-04 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Document workaround and root cause.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 5 — Changes

Purpose: Normal/Standard/Emergency change
Navigator: All > Change > All — Open direct
Direct: Open Changes

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-05 where the component supports records.
4. Configure form/view, states, mandatory fields, assignment, priority, SLA, closure, and reopen rules.
5. Test happy path plus reject/cancel/reassign/escalate/timeout/reopen.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 6 — Change Models

Purpose: Standardize change lifecycle
Navigator: All > Change > Administration > Models — Open direct
Direct: Open Change Models

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-06 where the component supports records.
4. Configure form/view, states, mandatory fields, assignment, priority, SLA, closure, and reopen rules.
5. Test happy path plus reject/cancel/reassign/escalate/timeout/reopen.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 7 — Catalog Items

Purpose: Requestable services
Navigator: All > Service Catalog > Maintain Items — Open direct
Direct: Open Catalog Items

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-07 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Requestable services.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 8 — Requested Items

Purpose: Fulfil catalog demand
Navigator: All > Service Catalog > Requested Items — Open direct
Direct: Open Requested Items

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-08 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Fulfil catalog demand.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 9 — Knowledge

Purpose: KCS and self-service content
Navigator: All > Knowledge > Articles — Open direct
Direct: Open Knowledge

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-09 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: KCS and self-service content.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 10 — SLA Definitions

Purpose: Response/resolution commitments
Navigator: All > Service Level Management > SLA Definitions — Open direct
Direct: Open SLA Definitions

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-10 where the component supports records.
4. Define start, pause, resume, stop, schedule, duration/target, and breach actions.
5. Test eligible, ineligible, paused, breached, and retroactive records.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 11 — Assignment Rules

Purpose: Route work consistently
Navigator: All > System Policy > Assignment — Open direct
Direct: Open Assignment Rules

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-11 where the component supports records.
4. Define eligibility, group/queue, skills, capacity, order, and no-match fallback.
5. Test normal routing, no qualified agent, capacity full, and reassignment.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

Component Lab 12 — SOW

Purpose: Agent workspace
Navigator: All > Service Operations Workspace
Direct: Open SOW

1. Confirm plugin, role, group, and prerequisite reference data.
2. Open the direct page and review OOTB fields, states, related lists, and existing records.
3. Create a pilot record named/prefixed LAB-12 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Agent workspace.
5. Test create/read/update/close and a negative-access case with the correct personas.
6. Impersonate requester/agent/manager/admin as applicable; record expected and actual results.
7. Capture evidence: URL, sys_id/number, screenshot, configuration decision, owner, and rollback step.

8. Integration architecture

Monitoring/event source → Incident; email intake; CMDB CI context; DevOps change evidence; external service desk via IntegrationHub/REST.

For every interface define:

Direct: Scripted REST · REST Messages · Connections

9. Reporting and Performance Analytics

KPIs: MTTA, MTTR, first-contact resolution, reopen rate, SLA attainment, change success rate, emergency-change rate, self-service deflection.

1. Build operational reports first.
2. Create role-based dashboard.
3. Add PA indicators/targets only when licensed and historical trend is required.
4. Validate report sharing and underlying ACLs.

Direct: Create Report · Reports · Dashboards · PA Indicators

10. Testing strategy

Direct: ATF Tests · ATF Suites

11. Deployment from development to production

1. Freeze scope and configuration.
2. Peer-review Update Set/App Repo contents.
3. Promote to test; Preview before Commit.
4. Resolve collisions deliberately.
5. Run ATF, security, integration, and UAT evidence.
6. Prepare data migration/cutover and communications.
7. Approve change record and rollback plan.
8. Deploy in agreed window.
9. Execute smoke tests and monitor.
10. Handover support ownership/runbooks.

Direct: Local Update Sets · Retrieved Update Sets · Upgrade History

12. Hands-on implementation lab

This full lab program covers platform readiness, security, all settings, module configuration, exception handling, experience, integration, data, reporting, testing, deployment, and operations.

Lab 0 — Instance and release readiness

1. Confirm Australia build at System Stats.
2. Verify entitlement/dependencies at Plugins.
3. Create Update Set LAB-MODULE-FOUNDATION.
4. Record baseline screenshots/properties and rollback owner.

Lab 1 — Personas, groups, roles, and security

1. Create requester, fulfiller/agent, manager, admin, auditor, and integration test users.
2. Create functional groups and grant roles to groups.
3. Build the role/access matrix and validate it through impersonation.
4. Test one unauthorized read and one unauthorized update.

Direct: Users · Groups · Roles · ACLs

Lab 2 — Module core happy path

Execute these module-specific steps:

• Create L1/L2 groups and assign itil roles through groups.
• Create a P1 incident; verify assignment and SLA attachment.
• Create a Problem from recurring incidents and document workaround.
• Create a Normal Change linked to the problem and CI; approve and close it.
• Publish a Knowledge article and link it to the resolved incident.
• Order one Catalog Item and complete REQ → RITM → SCTASK.

Lab 3 — Settings and exception paths

1. Complete every row in the settings workbook (§7).
2. Test missing mandatory data, invalid transition, reassignment, cancellation, rejection, timeout, and reopen.
3. Verify fallback assignment and ownership when no rule matches.
4. Confirm system properties differ correctly by environment.

Lab 4 — Automation, SLA, and notifications

1. Create/validate Flow trigger and all branches.
2. Configure approval timeout and escalation.
3. Validate SLA start/pause/resume/stop and breach.
4. Validate event registry, notification conditions, recipients, and email log.

Direct: Flow Designer · SLA · Notifications · Email Log

Lab 5 — Workspace, portal, and mobile

1. Configure persona lists/forms/actions.
2. Publish requester content/service where applicable.
3. Complete one end-to-end transaction as requester and fulfiller.
4. Validate accessibility, empty state, error state, and mobile behavior when licensed.

Lab 6 — Integration and migration

1. Define contract/schema, correlation key, authentication, and ownership.
2. Configure Connection Alias/Credential and environment property.
3. Test success, invalid payload, unauthorized, duplicate, timeout, retry, and replay.
4. Load a small migration file; validate coalesce, rejects, and reconciliation.

Direct: REST Explorer · Scripted REST · REST Messages · Transform Maps

Lab 7 — Reports, dashboard, and PA

1. Build volume, backlog, aging, SLA/target, exception, and trend reports.
2. Build manager/agent/executive dashboard variants.
3. Validate sharing roles and source ACL behavior.
4. If licensed, configure PA indicator source, collector, breakdown, target, and widget.

Lab 8 — ATF, UAT, and regression

1. Create smoke suite for create, route, progress, resolve/close.
2. Add security negative tests and core exception branches.
3. Execute UAT by persona and link defects to scenarios.
4. Export pass evidence and define upgrade regression suite.

Lab 9 — Deployment and hypercare

1. Preview Update Set in test and resolve all collisions.
2. Run ATF/UAT/integration/security checks.
3. Execute approved change and production smoke tests.
4. Monitor 24–72 hours; document defects, owners, SLA, and rollback decision.
5. Handover admin guide, fulfiller guide, dashboard, and support runbook.

Lab evidence: screenshots, record numbers, test-user results, Update Set, ATF result, dashboard, and rollback note.

13. Production operations

• Daily: queue/backlog, failures, SLAs, integration errors.
• Weekly: aging, throughput, exceptions, knowledge gaps.
• Monthly: KPIs, adoption, automation candidates, access exceptions.
• Quarterly: role review, retention, controls, upgrade readiness.

14. Definition of Done

• [ ] Entitlement/plugins and Australia compatibility confirmed
• [ ] Every §6 component lab completed with evidence
• [ ] Every §7 settings row has approved value, owner, transport, and test
• [ ] Signed scope, process, data, security, integration, KPI decisions
• [ ] Roles granted through groups and negative security tests passed
• [ ] Reference data, process, routing, SLA/entitlement configured
• [ ] Workspace/portal/mobile experience validated as applicable
• [ ] Integration controls and failure handling tested
• [ ] Reports/dashboard accepted by product owner
• [ ] ATF smoke + UAT + performance checks passed
• [ ] Deployment, rollback, support, and monitoring runbooks approved
• [ ] Knowledge transfer and operational ownership completed

15. 30/60/90-day maturity roadmap