sn_customerservice_case Table

Table Reference/sn_customerservice_case

The sn_customerservice_case table stores customer service case records in the Customer Service Management (CSM) application. It extends the task table and represents customer-reported issues, requests, and complaints managed by service agents.

What This Table Is

The sn_customerservice_case table stores customer service case records within ServiceNow's Customer Service Management (CSM) application. These records represent customer-reported issues, service requests, complaints, and inquiries that require resolution by customer service agents. Each case captures the full lifecycle of a customer interaction, from initial contact through resolution and closure.

The table extends the task table, inheriting core workflow fields like state, assigned_to, and priority, while adding customer-specific fields like account and contact. The CSM module owns this table and uses it to drive agent workspaces, SLA tracking, escalation workflows, and customer communication processes.

Customer service cases integrate heavily with knowledge management, chat transcripts, and customer portals. Unlike incidents which focus on service restoration, cases emphasize customer satisfaction and often involve back-and-forth communication. Cases can spawn child tasks, link to products and entitlements, and trigger complex routing rules based on customer tier and case category.

In large enterprises, this table typically contains 50K-500K+ active records with high insert volume during business hours. Performance considerations include proper indexing on account, state, and opened_at fields, as reporting queries frequently filter on these combinations.

When You'll Script Against This Table

You'll primarily script against sn_customerservice_case in Business Rules for workflow automation, Script Includes for agent workspace customizations, and Scheduled Jobs for SLA monitoring and escalation processing. The sn_customerservice_agent and sn_customerservice_manager roles control most access, with additional ACLs based on assignment group membership and account access.

Portal widgets and Service Portal pages frequently query this table to display customer case histories and status updates. Flow Designer and Workflow also operate on case records for approval processes, notifications, and integration with external CRM systems.

Auto-assigning cases based on account tier, product, and agent skills
Escalating overdue cases and triggering manager notifications
Calculating custom SLA metrics and customer satisfaction scores
Syncing case status with external CRM systems via REST APIs
Building custom dashboards and reports for case volume and trends
Validating entitlements and service level agreements on case creation
Implementing custom approval workflows for refunds and credits

Table Gotchas

⚠️

The state field uses different choice values than standard task tables. Cases use New (1), In Progress (2), On Hold (3), Resolved (6), Closed (7) — note that state 4 and 5 are skipped.

⚠️

The account field has complex ACL behavior — users can only see cases for accounts they have access to, which can cause unexpected empty query results if account access isn't properly configured.

The escalation field auto-increments on SLA breaches, but manually setting it doesn't trigger escalation workflows
Case numbers use a different format than incidents — they're prefixed with 'CS' and don't follow the standard task numbering sequence

⚠️

Queries on opened_at without proper indexing are expensive — always combine with account or state filters for better performance on large datasets.

The contact field can be null even when caller_id is populated — they serve different purposes in the customer hierarchy
Business Rules targeting case state changes fire frequently — use conditions carefully to avoid performance issues during bulk updates

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

As an extension of the task table, customer cases inherit all task functionality including workflow, SLAs, and approval capabilities. The most frequent joins occur with customer_account for customer information, customer_contact for contact details, and sys_user for assigned agents.

Cases heavily reference sys_user_group for assignment group routing and task_sla for SLA tracking. The sys_journal_field table captures work notes and customer communications, making it essential for case history reporting and audit trails.

Integration scenarios often involve querying cases alongside kb_knowledge for solution recommendations, cmn_cost_center for departmental reporting, and custom product catalog tables for entitlement validation. Customer satisfaction surveys stored in related tables also drive case closure workflows.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
state	choice	State	Case workflow state using values 1,2,3,6,7 (skips 4,5). Unlike incidents, 'Resolved' vs 'Closed' distinction affects customer portal visibility.
account	reference	Account	References customer_account table. Critical for ACL security and agent workspace filtering. Never null for valid cases.
contact	reference	Contact	References customer_contact table. Can be null even when caller_id populated — contact represents the customer hierarchy relationship.
escalation	integer	Escalation	Auto-increments on SLA breaches. Drives escalation workflows but manual changes don't trigger automation.
category	choice	Category	Drives assignment rules and SLA selection. Values controlled by sys_choice table, often customized per customer implementation.
subcategory	choice	Subcategory	Dependent choice based on category selection. Used for detailed case classification and reporting.
priority	choice	Priority	Inherited from task table. Often auto-calculated based on customer tier and category combination.
origin_id	reference	Origin	References sys_cs_origin table. Tracks whether case came from email, phone, chat, portal, etc.
product	choice	Product	Links to product catalog for entitlement validation. Critical for routing to product-specific support teams.
correlation_id	string	Correlation ID	External system identifier for integration scenarios. Must be unique when populated to prevent duplicate case creation.
customer_satisfaction	choice	Customer Satisfaction	CSAT score typically populated via survey workflows. Null until customer provides feedback after case resolution.
resolved_at	glide_date_time	Resolved	Auto-populated when state changes to Resolved. Different from closed_at — affects customer portal case visibility.
follow_up	glide_date_time	Follow up	Used for proactive customer outreach scheduling. Drives follow-up task creation via scheduled jobs.
reassignment_count	integer	Reassignment count	Auto-increments on assignment changes. High values trigger escalation workflows and management alerts.
business_impact	choice	Business Impact	Customer-reported impact level. Often different from system-calculated priority — used for escalation decisions.
watch_list	glide_list	Watch list	List of sys_user records to notify on case updates. Comma-separated user sys_ids stored as string.
case_data	json	Case Data	JSON field for storing structured case-specific information. Often used for integration payload storage and custom field extensions.

Common Queries

Get all active customer service cases

// Most basic query - cases not in closed state
var gr = new GlideRecord('sn_customerservice_case');
gr.addQuery('state', 'IN', '1,2,3,6'); // New, In Progress, On Hold, Resolved
gr.addQuery('active', true);
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    gs.print('Case: ' + gr.number + ' - ' + gr.short_description);
    gs.print('Account: ' + gr.account.getDisplayValue());
    gs.print('State: ' + gr.state.getDisplayValue());
    gs.print('---');
}

Find high priority cases for specific account assigned to agent group

// Business scenario: manager wants urgent cases for VIP customer
var gr = new GlideRecord('sn_customerservice_case');
gr.addQuery('account', 'account_sys_id_here'); // Specific customer account
gr.addQuery('priority', '<=', '2'); // High and Critical priority
gr.addQuery('state', 'IN', '1,2,3'); // Active states only
gr.addQuery('assignment_group.name', 'Customer Support Tier 2');
gr.orderBy('priority');
gr.orderBy('sys_created_on'); // Oldest first
gr.query();

while (gr.next()) {
    gs.print('URGENT: ' + gr.number + ' - Priority ' + gr.priority.getDisplayValue());
    gs.print('Contact: ' + gr.contact.getDisplayValue());
    gs.print('Escalation Level: ' + gr.escalation);
}

Cases requiring follow-up action within next 24 hours

// Real-world: daily scheduled job to identify cases needing proactive outreach
var tomorrow = new GlideDateTime();
tomorrow.addDaysUTC(1);

var gr = new GlideRecord('sn_customerservice_case');
gr.addQuery('state', 'IN', '2,3'); // In Progress or On Hold
gr.addQuery('follow_up', '<=', tomorrow); // Follow up due soon
gr.addNotNullQuery('follow_up');
gr.addQuery('assigned_to', '!=', ''); // Must be assigned
gr.query();

var cases = [];
while (gr.next()) {
    cases.push({
        number: gr.getValue('number'),
        assignee: gr.assigned_to.getDisplayValue(),
        customer: gr.account.getDisplayValue(),
        due: gr.getValue('follow_up')
    });
}
gs.print('Found ' + cases.length + ' cases requiring follow-up');

Count cases by state and priority for dashboard reporting

// Aggregate query for management dashboard
var ga = new GlideAggregate('sn_customerservice_case');
ga.addQuery('active', true);
ga.addQuery('opened_at', '>=', gs.daysAgo(30)); // Last 30 days
ga.addAggregate('COUNT');
ga.groupBy('state');
ga.groupBy('priority');
ga.query();

var metrics = {};
while (ga.next()) {
    var state = ga.state.getDisplayValue();
    var priority = ga.priority.getDisplayValue();
    var count = ga.getAggregate('COUNT');
    
    if (!metrics[state]) metrics[state] = {};
    metrics[state][priority] = count;
    gs.print(state + ' / ' + priority + ': ' + count + ' cases');
}

GOTCHA: Wrong way vs right way to query by customer account access

// WRONG: This fails silently due to ACL restrictions
var badQuery = new GlideRecord('sn_customerservice_case');
badQuery.addQuery('number', 'CONTAINS', 'CS');
badQuery.query(); // May return empty due to account ACLs

// RIGHT: Always filter by account first when user context matters
var goodQuery = new GlideRecord('sn_customerservice_case');
// Get accounts user has access to first
var accountGR = new GlideRecord('customer_account');
accountGR.query();
var accountList = [];
while (accountGR.next()) {
    accountList.push(accountGR.getValue('sys_id'));
}

// Then query cases with account filter
goodQuery.addQuery('account', 'IN', accountList.join(','));
goodQuery.addQuery('number', 'CONTAINS', 'CS');
goodQuery.query(); // Returns expected results

Related Tables

task sys_user sys_user_group task_sla

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue