Real-time proactive resolution
Summarize
Summary of Real-time proactive resolution
Real-time proactive resolution in ServiceNow’s DEX enables rapid detection and remediation of device and application issues before users are impacted. It leverages metric rules, alerts, and auto-correction scripts to monitor system health at configurable intervals (every 5, 10, or 15 minutes) and automatically triggers corrective actions when thresholds are breached.
Show less
Key Features
- Metric-based detection: Uses metric rules to evaluate time-series data, generating alerts when metrics exceed defined thresholds (e.g., disk usage or crash frequency).
- Auto-correction scripts: Employs check definitions within policies to detect and fix common issues (like VPN reconnection or service restarts) on endpoints, even offline.
- Alert generation and correlation: DEX creates events and alerts in tables, grouping device alerts by metric rule within a configurable time window (default one hour), and tracks impacted users and devices.
- Remediation actions: Supports multiple action types including executing commands/scripts, creating incidents in ServiceNow, providing self-help instructions, or directing users to URLs.
- Notification and engagement options: Remediation can be silent (automatic), notify and request user consent (via Virtual Agent, email, or desktop notifications), or notify only without action.
- Fallback procedures: If users do not respond or the issue persists, fallback actions such as incident creation or live agent connection are triggered.
- Automatic alert closure: Alerts and experience issues close automatically when impacted devices are no longer affected.
Practical Benefits for ServiceNow Customers
By implementing real-time proactive resolution, customers can minimize user disruption through early issue detection and automated remediation. The solution enhances operational efficiency by reducing manual intervention, supports offline device management via auto-correction scripts, and ensures comprehensive tracking and escalation through integrated alert and incident management. Customers can tailor remediation workflows to their organizational needs and maintain visibility into issue resolution status.
Use metric rules, alerts, and auto-correction scripts to detect and remediate device and application issues within minutes, before users are affected.
DEX collects metric data at configurable intervals (every 5, 10, or 15 minutes depending on the metric configuration) and evaluates conditions that indicate a device or application issue. When a threshold is breached, DEX generates events and alerts that trigger remediation actions.
DEX supports two real-time detection and remediation approaches:
- Metric-based: Uses metric rules to evaluate time-series data and generate alerts. Suitable for conditions that can be expressed as a threshold on collected metrics, such as disk usage or crash frequency.
- Auto-correction scripts: Uses check definitions wrapped in policies to detect and correct conditions at a defined frequency. Suitable for common detect-correct scenarios that don't require additional analysis or correlation, and that must work even when the device is offline.
Alert generation
When a metric rule detects that a device or application metric has breached a threshold, DEX generates events and alerts in the following sequence:
- DEX evaluates metric rules against incoming metric data for each device.
- For each device that breaches a threshold, DEX creates one event in the
em_eventtable. - DEX generates one alert per device in the
em_alerttable (device alerts) or one alert per application and metric rule combination (application alerts). - DEX groups device alerts using the alert correlation rule available with the base system, which consolidates all device alerts for the same metric rule combination within a
configurable time window. The default window is one hour and is controlled by the system property
sn_dex.alert.correlation_rule.device_period. - For application alerts, subsequent evaluations for the same application and metric rule update the same
dex_alert_metadatarecord with the new event ID and impacted devices. All new events for the same application and metric rule map to the same alert number until the alert is closed. - Impacted users and devices are recorded in the
dex_alert_impacted_userstable. Additional details are recorded index_alert_metadata.
Alert remediation
When a resolution is defined in the metric rule, DEX generates an experience issue per impacted user in the sn_pren_experience_issue table. Remediation can be silent (executed automatically without user interaction) or can
engage the end user through a notification.
- Remediation action types
-
- Remedial action: Executes a CI action (command or script on the endpoint), catalog item, flow, or Virtual Agent (VA) topic.
- Create incident: Opens an incident record in ServiceNow.
- Self-help instructions: Delivers instructions to the end user.
- URL: Directs the end user to a resource URL.
- Silent execution
- The remediation action runs automatically on the device without notifying the end user.
- Notify and engage
- DEX sends the end user a notification through a VA push notification, email, or desktop push notification, then requests consent before executing the action. After execution, the user confirms resolution or escalates.
- Notify only
- DEX notifies the end user without prompting for consent or executing an action.
- Fallback configuration
- If the user does not respond or confirms that the issue is not resolved, a fallback action runs. Fallback options include doing nothing, creating an incident, or connecting the user to a live agent.
When all devices are removed from the impacted device list, DEX closes the alert automatically. For device alerts, the experience issue is also closed. For application alerts, the alert closes when no devices remain in the impacted list.
Auto-correction scripts
Auto-correction scripts use check definitions wrapped in policies to detect and correct issues at a configured frequency. This approach is suitable for common detect-correct scenarios, such as reconnecting a VPN, connecting to Wi-Fi, or restarting a service, that don't require correlation with metric data or other data collected with DEX.
Auto-correction scripts run on the endpoint and work even when the device is not connected to the internet or to the ServiceNow instance.