Building a Case Auto Closure Process in ServiceNow

When “Awaiting Customer” Becomes “Forever”

In any high volume customer support operation, one of the most common operational challenges is the “zombie case” tickets that remain open simply because a customer has stopped responding. These unresolved cases clog up the support queue, skew metrics, and divert valuable engineering time to manually check in on issues that are often already resolved.

We faced this exact challenge. To maintain a clean support pipeline and focus our team’s efforts where they matter most, we knew we needed an automated solution. This is the story of how we designed and implemented a case auto-closure process in ServiceNow.

Why a Simple Timer Wouldn’t Work (Our Core Complexities)

However, simple “close after X days” timer was not an option. A naive solution could prematurely close a case when the customer was just busy. We needed a system that looks for different conditions before closing the cases. Our solution needed to be smarter and address key challenges:

1. Not All Cases Are Equal: The system needed to be targeting only specific case types (like P0-P3 Incidents, Queries) and their current status.
2. Existence of Dependent Tickets: A single “parent” case can often generate other work, like a Service Request (SR) or a Change Request (CR), especially for our Managed Cloud accounts. We couldn’t close a customer’s main case while other teams were still actively working on a dependent CR. The system had to be smart enough to check for these ongoing dependencies first.
3. The Human Factors (The “On-Hold”): Sometimes customers just need more time. A rigid flow that closes a ticket on a customer who is on vacation is a poor experience. We needed a “pause button”, an “On-Hold” flag that could set based on a customer’s request, but that would also automatically resume the closure process after a set period (e.g., one month) to prevent cases from being forgotten.

From Idea to Blueprint: A Collaborative Design Process

First, we analyzed the initial requirement document to understand the core business goals. We then conducted a gap analysis by evaluating the default auto closure feature in ServiceNow. This immediately showed us where the out-of-the-box functionality fell short of our needs, particularly around adding multiple reminders before closing the case, addressing the case dependencies and when the customer’s request for on-hold.

So based on requirement identification and analysis, we designed a flow to include the auto closure logic. Below is a sample design of what we have came up with.

The proposed feature and the design was presented to the leadership teams to get feedback. This feedback loop was crucial, as it brought in diverse perspectives and helped refine the logic to handle complexities.

Customizing ServiceNow for Our Logic

The default ServiceNow workflows couldn’t handle our specific requirements, so we implemented several key customizations.

This was a collaborative effort. A partner team developed the foundational logic for case dependency tracking (linking parent cases to child cases) and built the “On-Hold” UI option for our support agents.

Get Prabod Dunuwila’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

To drive the auto-closure workflow itself, we introduced two crucial attributes to the case record:

• Auto Closure State: A new field to “remember” where the case is in the process (e.g., Default, First_Comment_Sent, Second_Comment_Sent).
• Auto Closure State Time: A timestamp that records when the case entered its current state.

These two attributes work together for our automation, allowing the system to precisely manage the wait periods between reminders and know exactly what to do with the case next.

The New Auto Closure Flow

With the new attributes and dependencies in place, we built the complete workflow. This required two distinct pieces of logic:

1. The Main Auto Closure Trigger

We developed the main trigger, a scheduled job that runs daily. It’s a multi-stage process that handles all eligible cases based on their Auto Closure State:

1. Handles “On-Hold” Cases: First, it finds all ON_HOLD cases whose hold period has expired and updates them, allowing them to re-enter the main flow.
2. Processes DEFAULT Cases: It then finds all eligible cases ( Solution Proposed state / Awaiting Info state) in the DEFAULT step. It sends the First Reminder and updates the state to First_Comment_Sent.
3. Processes First_Comment_Sent Cases: Next, it finds cases that have been in the first reminder state for X days, sends the Second Reminder, and updates the state to Second_Comment_Sent.
4. Processes Second_Comment_Sent Cases: Finally, it finds cases that have been in the second reminder state for Y days, sends the Final Closing Comment, and closes the case.

For every eligible case it finds, it looks to see if that case has any active, ongoing child cases.

If, and only if, a case has no ongoing child cases, the workflow proceeds to update it. This update is what officially moves the case into the auto-closure-reminder flow.

After adding the first comment based on the above logic, the subsequent reminder comments are added and case is closed off.

2. The “Reset” Trigger (Handling Customer Replies)

A critical requirement was to immediately halt and reset this process the moment a customer responds.

To achieve this, we built a second trigger that activates on any case update. This trigger’s job is to watch for customer activity. If a customer adds a comment (which typically moves the case to a “Waiting” status), this trigger instantly sets the auto_closure_state field back to DEFAULT.

This simple reset ensures the automated ‘Timer’ is immediately stopped and the customer’s case is back in the active state. The auto-closure process will only start again from beginning once the support team moves the case back to a ‘Solution Proposed’ or ‘Awaiting Info’ state.

The Impact: A Cleaner Queue and a More Focused Team

By investing time in collaborative design and implementing a few key customizations, we’ve transformed our case management process. This new automated workflow has already had a significant impact:

• Support engineers can focus on active, complex problems instead of manually chasing non-responsive tickets.
• Our support metrics will now be more accurate, reflecting a true active workload.
• Our customers are better served by a clear, predictable communication process that still gives them control.

This project is a perfect example of how thoughtful automation doesn’t just improve efficiency, it allows our human experts to focus on what they do best.