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

CSM — 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: ../CSM.md
All implementation guides: INDEX.md

0. Outcome and guardrails

Customer Service Management: Manage B2B/B2C customer support with entitlement-aware cases, routing, SLAs, knowledge, and customer portals.

• 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: Account / Consumer → Contact → Product / Installed Product → Entitlement → Case → Tasks / Escalation → Resolution → Knowledge / Survey

2. Discovery workshops and scope

Run these workshops before configuration:

3. Licensing, plugins, and release readiness

Expected products/plugins: Customer Service Management; CSM Configurable Workspace; Advanced Work Assignment; Customer Service Portal; Performance Analytics (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: sn_customerservice_agent, sn_customerservice_manager, sn_customerservice_admin, awa_admin, knowledge

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 CSM: 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 — Accounts

Purpose: B2B customer master
Navigator: All > Customer Service > Accounts — Open direct
Direct: Open Accounts

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 ownership, required fields, references, lifecycle, security, and automation for: B2B customer master.
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 2 — Contacts

Purpose: People linked to accounts
Navigator: All > Customer Service > Contacts — Open direct
Direct: Open Contacts

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 ownership, required fields, references, lifecycle, security, and automation for: People linked to accounts.
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 3 — Consumers

Purpose: B2C customer master
Navigator: All > Customer Service > Consumers — Open direct
Direct: Open Consumers

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 ownership, required fields, references, lifecycle, security, and automation for: B2C customer master.
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 4 — Cases

Purpose: Customer support work
Navigator: All > Customer Service > Cases — Open direct
Direct: Open Cases

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 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 5 — Entitlements

Purpose: Validate support rights
Navigator: All > Customer Service > Entitlements — Open direct
Direct: Open Entitlements

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. 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 6 — Products

Purpose: Product context
Navigator: All > Customer Service > Products — Open direct
Direct: Open Products

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 ownership, required fields, references, lifecycle, security, and automation for: Product context.
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 7 — AWA Queues

Purpose: Omnichannel routing
Navigator: All > Advanced Work Assignment > Queues — Open direct
Direct: Open AWA Queues

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. 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 8 — Service Channels

Purpose: Define routable channels
Navigator: All > Advanced Work Assignment > Service Channels — Open direct
Direct: Open Service Channels

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. 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 9 — CSM Workspace

Purpose: Agent case handling
Navigator: All > Customer Service > CSM Workspace — Open direct
Direct: Open CSM Workspace

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 persona landing page, lists, forms, actions, navigation, and audience.
5. Validate desktop/mobile accessibility and complete the process by impersonation.
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 — Customer Portal

Purpose: Customer self-service
Navigator: All > Service Portal > Portals — Open direct
Direct: Open Customer Portal

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. Configure persona landing page, lists, forms, actions, navigation, and audience.
5. Validate desktop/mobile accessibility and complete the process by impersonation.
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 — Knowledge

Purpose: Resolution and deflection
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-11 where the component supports records.
4. Configure ownership, required fields, references, lifecycle, security, and automation for: Resolution and deflection.
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 12 — Case SLAs

Purpose: Case commitments
Navigator: All > Service Level Management > SLA Definitions — Open direct
Direct: Open Case SLAs

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. 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.

8. Integration architecture

CRM/account master; telephony/contact center; email/chat; product telemetry; order/ERP; ITSM escalation when an internal service causes customer impact.

For every interface define:

Direct: Scripted REST · REST Messages · Connections

9. Reporting and Performance Analytics

KPIs: Case volume, first response, resolution time, SLA attainment, backlog age, reopen rate, CSAT, deflection, cases per account/product.

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 one B2B Account, two Contacts, and a product/entitlement.
• Create a Case from the portal or agent workspace.
• Configure AWA queue eligibility, capacity, and assignment.
• Apply an entitlement and SLA; validate pause/stop conditions.
• Escalate a case, create a task, resolve, and send a survey.
• Publish a Knowledge article and verify portal visibility.

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