Using AI to Identify High Risk Application Services & Auto Create One Incident per Service
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Community,
We’re exploring an automation approach where an AI model outputs a list of high‑risk application services, and ServiceNow automatically creates one consolidated Incident per service whenever active alerts are detected.
High‑Level Idea
- AI provides a dynamic list of priority application services
- A scheduled Flow/Scheduled Script iterates through that list
- If a service has active alerts → create one Incident summarizing all issues
- Prevent duplicates by checking for already‑open Incidents
Goal
Reduce alert noise, avoid ticket storms, and help teams focus on services with the highest operational risk.
Looking for Input On
- Best way to avoid duplicate Incidents
- Whether Flow Designer or a scheduled Script is better suited
- Any patterns used for grouping Event Management alerts by service
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
How do you expect AI to define if an application service is a priority one?
Your application services are in the system, so you must have an idea in your mind that you want AI to check on.
Now ask yourself if you really want to pay for AI calls to get that list every time, when a simple glide record could probably do the same. Why would you want to use AI for this? What is the upside, besides being able to say 'we are using AI'?
Also: a scheduled flow iterates through a list of alerts to only create one incident: I hope that you don't have any critical services, because they are only checked on a schedule.
Be aware that AI uses tokens and you will be paying for that (probably a lot). So first define the WHY of AI use if it can be resolved in a lest costly manner.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Mark is correct in the sense that not everything is suited to AI. Some of the steps in this automation should use deterministic logic, such as providing a list of priority application services, otherwise you may not see consistent results, especially with edge cases, due to the non-deterministic nature of AI . You can invoke a Skill or an AI Agent, for other steps, such as the Summarization skill for "summarizing all issues". Therefore, you need to check if a deterministic or non-deterministic logic is he best approach for each step in your automation, especially when the output in one step is the input for the next step.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
when you have Application Services Discovered and Mapped using ITOM Visibility (Disco+ Service Mapping) then ServiceNow Automatically correlated the Alerts - We call it CMDB based Correlation. This is very effective in Noise reduction - You can explore more here-
https://www.servicenow.com/community/itom-forum/cmdb-correlation-in-the-event-management/m-p/2498348
As i see in your Original Requirement also - You are looking for AI to Connect all the DOTS Means Connect Alert of all Component of a Given Application Service and Make one Primary Alert and one Incident.
There many ways to Implement event correlation in ServiceNow.
- Rule-Based (Manual Configuration): Users define specific criteria, such as filters or scripts, to designate a primary alert and associated secondary alerts within a set timeframe. These are best for known infrastructure relationships (e.g., specific application servers always impacting a particular database).
- Automated (Service Analytics): ServiceNow's built-in machine learning analyzes alert patterns automatically, grouping them based on commonality, such as the same CI (Configuration Item) or Node name.
- CMDB-Based: Uses the Configuration Management Database (CMDB) to identify relationships between CIs, such as child-to-parent dependencies. If a business service is impacted, all downstream CIs with alerts are grouped under the primary service alert.
- Text-Based/Machine Learning (Clustering): Uses machine learning algorithms to identify patterns in the text of incoming alerts (e.g., similar error messages across different nodes). This helps group alerts from different sources that share a common context.
Regards
RP

