ServiceNow CSM: Case In Progress (CSM 7)

Managing complex customer service operations requires more than just tracking an issue from open to close. When a critical issue strikes—like an enterprise mail server outage—resolving it involves cross-departmental coordination, clear bottleneck tracking, strict priority management, and constant stakeholder communication.

Within modern CSM frameworks (such as ServiceNow), managing a Case In Progress relies on a robust ecosystem of tasks, automated statuses, escalation workflows, and communication tools. This comprehensive guide breaks down how these components work together to accelerate resolution times and keep everyone aligned.

1. Case Tasks: Structuring and Assigning the Work

What are Case Tasks?

A Case Task documents the granular, additional work required to resolve a parent case. Instead of burying action items in work notes, Case Tasks organize the workload, assign clear ownership, and provide total visibility to both internal teams and external customers via the Task Related List.

Example: For a mail server outage case, an agent might spin up three distinct Case Tasks:

1. Check current server patch levels.
2. Review the upcoming patching schedule.
3. Schedule the emergency patch installation.

Assignment and Portal Visibility

Case Tasks are highly flexible and can be assigned to the handling agent, other internal agents, service provider employees, or even the customers themselves.

• Internal Requirements: To be assigned a task, a service provider employee must hold the sn_customerservice.case_task_agent role.
• Customer Visibility: End users can view and manage tasks assigned to them via the My Case Tasks List on customer portals. To protect internal operations, customers only see a restricted set of fields: Subject, Contact, Account, Consumer, Parent Case, and Priority.

By default, Case Tasks inherit core attributes from the parent case (Contact, Account, Consumer, and Parent). While agents can modify these fields to include related third parties, the platform guards data integrity by generating an alert if an agent attempts to delete related parties while a case remains open.

Driving Efficiency with Service Definitions

To prevent agents from manually guessing what tasks are needed for complex issues, administrators use Service Definitions—rules that map the relationships between Products, Service Catalog Items, and Case Types.

Step	Phase	Actor	System Action / Trigger
1	Customer Initiates Case	Customer	The initial contact or issue is submitted via the portal, email, or phone.
2	Case Type Identified	System / Agent	The category and classification of the issue are determined.
3	Service Definition Applied	System	The platform automatically maps relationships between the product, catalog item, and case type.
4	Task Service Selector Pops Up	System UI	A contextual modal displays only the pre-approved task types permitted for this specific scenario.
5	Agent Selects Pre-Approved Tasks	Agent	The handling agent picks and assigns the standardized sub-tasks required to resolve the issue.

This structural framework enables powerful task automation:

• Reusable Entities: A single Case Task template can be mapped to multiple services.
• The Task Selector: When an agent works a specific case type, a Case Task Service Selector popups up, displaying only the pre-approved, valid task types allowed for that specific scenario.
• Parent-Child Architecture: Admins can establish parent-child hierarchies between Case Type Definitions and Case Task Type Definitions to handle highly complex, multi-tiered workflows (like an “Onboarding” case type that triggers “New Business Credit Card” and “Document Verification” sub-tasks).

2. Action Status & Blocking Tasks: Spotting Bottlenecks

An automated, visual indicator system ensures cases do not stall without anyone noticing.

Action Status Visual Clues

The system automatically updates a case’s Action Status column using predefined case flows, giving agents an instant, color-coded health check of their queue:

• ● Blue Indicators: Cases that need attention, are waiting for internal review, or require immediate agent input.
• ● Red Indicators: Cases that are hard-blocked by an external dependency or waiting entirely on customer feedback.

If automated tracking is insufficient for a unique situation, agents and managers can manually flag a case by enabling the Needs Attention field.

Tracking Dependencies with Blocking Tasks

When a case hits a wall, a Blocking Task is created to document the exact dependency. This relationship directly shifts the case’s Action Status into one of three blocked states:

Blocked State	Trigger Mechanism	Resolution / Unblocking
Blocked by Customer	Agent requests more information or files from the end user.	Customer replies or uploads info -> Task auto-resolves -> Shifts to Blue (Needs Attention).
Blocked Internally	Case is tied to an open internal task (e.g., an active Problem record or IT engineering task).	Internal team resolves the underlying engineering/problem task -> Case automatically unblocks.
Blocked Internally & By Customer	Simultaneous internal dependencies and outstanding customer requests exist.	Both dependencies must be resolved before the block completely clears.

Pre-Configured Automation via Flow Designer

This entire blocking ecosystem runs out-of-the-box via Flow Designer through the Case Action Status plugin (enabled by default). These actionable case flows monitor case conditions—such as a state changing to “Awaiting Info”—and instantly spin up or tear down the corresponding “Blocked by” records. Admins can easily navigate to Customer Service > Administration > Actionable Case Flows to tweak or disable specific flows.

3. Escalations & De-Escalations: Elevating Visibility

When a standard workflow fails to meet deadlines or satisfy a customer, the escalation framework steps in to elevate the issue’s visibility and severity across the organization.

The Escalation Lifecycle

To initiate an escalation, a user must hold the sn_customerservice.escalation_requester role. The agent opens the active case, clicks Create Escalation, and populates the required fields:

• Request Source: Customer or Internal.
• Reason: Lack of progress, Inactivity, or a Customer-imposed deadline.
• Justification & Details: Text explanation, optional Severity rating, Trend tracking (Improving, Declining, Same), and an operational Watch List.

⚠️ System Constraint: To prevent chaotic management overhead, a case can only have one active case escalation open at any single given time.

Creating an escalation triggers three immediate platform actions:

1. A distinct, related Escalation Record is generated.
2. A strict Escalation SLA is attached to the case (e.g., “Escalated case response – 8 hours”).
3. The parent case’s Activity Notes are stamped with the escalation details.

Case Escalation vs. Account Escalation

Organizations can escalate a single issue (Case Escalation) or an entire client relationship (Account Escalation). They behave differently under the hood:

Feature	Case Escalation	Account Escalation
Primary Manager	Customer Service (CS) Agent	Account Escalation Manager
Operational Scope	A single, isolated Case	Multiple linked Cases across the client profile
Audit Trail & Updates	Logged directly into the Case Work notes	Logged separately as a consolidated report (kept off the Account record)
SLA Paradigm	Driven by Case Impact and Urgency	Driven by the client’s Contractual Account SLA timeline

Process Flow and Governance

Escalations follow a strict state lifecycle managed by the approver_user role via the My Approvals module:

Current State	Transition Trigger	Outcome State	Platform Actions & Visibility
Requested	Escalation record is initially created by an eligible requester.	Awaiting Action	The request enters the approver_user queue via the My Approvals module.
Requested	Approver signs off OR configuration bypasses approval rules.	Escalated	State updates to Escalated; strict Escalation SLAs attach to the parent record; highlight styles activate.
Requested	Approver rejects the escalation request.	Declined	State updates to Declined; approver comments are permanently stamped onto both the escalation and the case logs.

When an approver inputs their decision and notes, the system automatically writes those comments to the activity logs of both the escalation record and the parent case.

De-Escalation

Once the high-pressure conditions clear, a user with the sn_customerservice.deescalation_requester role can click De-escalate Case. This action immediately:

• Closes out the active escalation record.
• Completes and stops the associated Escalation SLA clock.
• Logs the closure to the case Activity stream.
• Note: Unlike creating an escalation, de-escalation requires no complex approval workflows.

Admin Configurations: Templates and Severity Styles

Admins configure these workflows using Escalation Templates (the standard options being Case and Account). These templates dictate the approval chains, workflow routing, and who gets added to the automated notification Watch List.

Furthermore, admins define Escalation Severity styles to provide quick visual identifiers in lists, mapping high-severity issues to deep red highlights and medium-severity issues to orange alerts.

4. Case Action Summaries: Streamlining Communication

During high-priority incidents or mass outages, agents can become overwhelmed by status update requests from executives and customers. Case Action Summaries solve this by creating clear, concise status updates.

The Creation and Publishing Workflow

Agents compile a summary that balances internal technical milestones with customer-facing explanations. Before anything goes live, the agent can preview the output to check its layout and tone.

When ready to distribute, the system offers two primary publishing paths:

Distribution Method	Target Audience / Location	Impact on Parent Case	Automated Notifications
Publish to Case	Customers & Internal Agents	• Customer-visible info updates Additional comments. • Full summary updates internal Work notes.	No outbound emails are triggered.
Publish to Case & Notify	Customers, Internal Agents, & Key Stakeholders	• Performs the exact same updates to Additional comments and Work notes.	Instantly fires an email notification containing the summary to the Additional internal recipients list.

By connecting these summaries directly to the case lifecycle, administrative overhead is minimized: the moment the parent case is marked Closed, the platform automatically wraps up and closes the corresponding Case Action Summary.

Summary Checklist for Admins & Agents

• For Agents: Use Case Tasks to offload sub-steps to specialized teams, pay attention to Red/Blue Action Status icons to prioritize your day, and leverage Case Action Summaries to handle stakeholder communication updates in one click.
• For Admins: Harness Service Definitions to enforce standardized task templates based on Case Types, deploy Flow Designer to manage automated Blocking Tasks, and customize Escalation Templates to ensure high-priority issues route to the correct managers instantly.

---

Review

Category	Key Concept / Feature	Critical Details
1. Case Tasks	Purpose	Break down granular work on a parent case without burying items in work notes. Visible to both internal teams and customers.
	Roles & Permissions	Internal agents need sn_customerservice.case_task_agent to be assigned a task.
	Portal Visibility	Customers can only see a restricted set of fields: Subject, Contact, Account, Consumer, Parent Case, and Priority.
	Service Definitions	Admin-configured rules mapping Products, Catalog Items, and Case Types. Triggers the Case Task Service Selector popup to show only pre-approved task types.
2. Action Status & Blocks	Visual Clues (Indicators)	● Blue: Needs attention, waiting for internal review, or agent input. ● Red: Hard-blocked by external dependency or waiting on customer feedback.
	Blocking States	Blocked by Customer: Auto-shifts to Blue once customer replies. Blocked Internally: Auto-unblocks when the underlying internal/Problem task resolves. Blocked Internally & By Customer: Both dependencies must clear to unblock.
	Backend Engine	Driven out-of-the-box by Flow Designer via the Case Action Status plugin. Located at Customer Service > Administration > Actionable Case Flows.
3. Escalations	Initiation Roles	Must hold sn_customerservice.escalation_requester to create an escalation.
	System Constraint	Only ONE active case escalation can be open at any single given time.
	Platform Actions	Generates an Escalation Record, attaches a strict Escalation SLA, and stamps the parent case’s Activity Notes.
	Case vs. Account	Case Escalation: Managed by CS Agent, impacts a single case, logged in Case Work notes. Account Escalation: Managed by Account Escalation Manager, impacts multiple cases, logged as a separate consolidated report (not on the Account record).
	Approval State Workflow	State lifecycle: Requested -> Awaiting Action (in approver_user queue via My Approvals) -> Escalation Approver signs off -> Escalated (or Declined).
	De-Escalation	Requires sn_customerservice.deescalation_requester. Closes the record and stops the Escalation SLA clock immediately (No approval workflow required).
4. Case Action Summaries	Distribution Paths	Publish to Case: Updates Additional comments (customer) and Work notes (internal). No emails sent. Publish to Case & Notify: Same updates PLUS instantly emails the Additional internal recipients list.
	Lifecycle Automation	When the parent case is marked Closed, the platform automatically wraps up and closes the associated Case Action Summary.