Auto Resolve Incident After 15 Business Days - Different approaches

ananyanoone
Tera Contributor

6 hours ago

Auto Resolve Incident After 15 Business Days (ServiceNow)

Use Case Overview

This is a very common requirement in ServiceNow projects.

Scenario:
When an Incident is moved to On Hold with the On Hold Reason = Awaiting Caller, the support team is waiting for information from the caller. To avoid incidents staying in On Hold forever:

  • Reminder notifications should be sent to the caller at regular intervals (for example, after 5 days and 10 days).
  • If the caller does not respond and the incident is still in On Hold, the incident should be automatically resolved after 15 business days.
  • The 15 days must be working days only and should follow a specific schedule (for example, 9 to 5 Monday–Friday, excluding holidays).

This article explains different approaches to implement this requirement, along with their pros and cons.

Key Requirements

  • Trigger only when:
    • State = On Hold
    • On Hold Reason = Awaiting Caller
  • Send reminder notifications (for example, Day 5 and Day 10)
  • Auto-resolve after 15 business days
  • Business days should follow a ServiceNow schedule

Approach 1: Flow Designer (Traditional Approach)

How it works

  1. Create a Flow with trigger:
    • Table: Incident
    • Condition: State changes to On Hold AND On Hold Reason = Awaiting Caller
  2. Add a Wait action for a configurable number of days (stored in a system property).
  3. After every 5 days, fire an event to trigger reminder notifications.
  4. After 15 days, update the Incident state to Resolved and send a resolution notification.

Advantages

  • Easy to understand
  • Low-code / no-code solution
  • Good for small implementations

Drawbacks

  • Every On Hold incident creates a Flow execution
  • These executions remain in waiting state for up to 15 days
  • If there are many incidents, this results in:
    • Large number of waiting executions
    • Potential performance impact

This approach is not recommended for high-volume environments.

 

 

Approach 2: Scheduled Business Rule (Using sys_updated_on)

This approach is similar to the out-of-box Auto Close Incident logic.

How it works

  1. Store the following values in system properties:
    • Schedule ID (business calendar)
    • Auto-resolve days (15)
  2. Create a Scheduled Business Rule (runs hourly or daily).
  3. Use sys_updated_on as the starting point to calculate elapsed business days.
  4. Fire reminder events using gs.eventQueue().
  5. Resolve the incident once the count reaches 15 business days.

Sample Code Snippet

var scheduleId = gs.getProperty('incident.auto.resolve.schedule');

var schedule = new GlideSchedule(scheduleId);

 

var startDate = new GlideDateTime(current.sys_updated_on);

var now = new GlideDateTime();

 

var businessDuration = schedule.duration(startDate, now);

var businessDays = businessDuration / (8 * 60 * 60 * 1000); // assuming 8-hour workday

 

if (businessDays >= 15) {

    current.state = 6; // Resolved

    current.update();

}

Drawbacks

  • sys_updated_on changes whenever:
    • An agent adds comments
    • Any field is updated
  • This resets the day count, which makes the calculation inaccurate

Because of this, this approach is not reliable.

Approach 3: Custom Field (On Hold At)

How it works

  1. Create a custom field on Incident, for example: u_on_hold_at.
  2. Populate this field when the incident moves to On Hold.
  3. Use this field as the starting date for business-day calculation.

Drawbacks

  • Creating custom fields on global tables like Incident is not a best practice
  • Adds long-term maintenance overhead

This approach works technically but is generally not recommended.

Approach 4: After Business Rule + Scheduled Events (Recommended)

How it works

  1. Create an After Business Rule on Incident:
    • Trigger: State changes to On Hold
    • Condition: On Hold Reason = Awaiting Caller
  2. In the Business Rule:
    • Calculate future dates using a GlideSchedule
    • Schedule events (no waiting)
  3. Create Script Actions for these events:
    • Day 5 → Reminder notification
    • Day 10 → Reminder notification
    • Day 15 → Auto-resolve incident

Example Business Rule Code

var scheduleId = gs.getProperty('incident.auto.resolve.schedule');

var schedule = new GlideSchedule(scheduleId);

 

var onHoldTime = new GlideDateTime();

 

var reminder1 = schedule.add(onHoldTime, 5 * 8 * 60 * 60);

var reminder2 = schedule.add(onHoldTime, 10 * 8 * 60 * 60);

var resolveTime = schedule.add(onHoldTime, 15 * 8 * 60 * 60);

 

gs.eventQueueScheduled('incident.reminder.5days', current, '', '', reminder1);

gs.eventQueueScheduled('incident.reminder.10days', current, '', '', reminder2);

gs.eventQueueScheduled('incident.auto.resolve', current, '', '', resolveTime);

Advantages

  • No long-running waiting executions
  • Accurate business-day calculation
  • Clean separation of logic (BR + Script Actions)
  • Scales well for large volumes

Approach 5: Using sys_audit Table (Best and Cleanest Approach)

How it works

  1. When an incident moves to On Hold with reason Awaiting Caller, ServiceNow creates audit records in sys_audit.
  2. Two records are created:
    • State change
    • On Hold Reason change
  3. Use the created time of these audit records as the true starting point.
  4. Create a Scheduled Business Rule (hourly or daily):
    • Query incidents in On Hold
    • Fetch audit record timestamp
    • Calculate business days using GlideSchedule
  5. Send reminders and auto-resolve accordingly.

Example Audit Query

var audit = new GlideRecord('sys_audit');

audit.addQuery('tablename', 'incident');

audit.addQuery('fieldname', 'state');

audit.addQuery('newvalue', '3'); // On Hold

audit.addQuery('documentkey', current.sys_id);

audit.orderByDesc('sys_created_on');

audit.setLimit(1);

audit.query();

 

if (audit.next()) {

    var onHoldDate = new GlideDateTime(audit.sys_created_on);

}

Advantages

  • No custom fields required
  • Accurate start time
  • Not affected by later updates or comments
  • Uses existing platform data

Drawbacks

  • Slightly more complex logic

Overall, this approach has minimal drawbacks and is suitable for enterprise-scale implementations.

Conclusion

For most real-world ServiceNow implementations, using Scheduled Events or the sys_audit table provides the best balance of accuracy, performance, and maintainability.

I hope this article helps you design a clean and scalable auto-resolve solution in ServiceNow.

 

0 Helpfuls
  • 56 Views
0 REPLIES 0