Shared impacted services alert grouping

  • Release version: Australia
  • Updated June 16, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Shared impacted services alert grouping

    The Shared impacted services alert grouping feature in ServiceNow Event Management automatically consolidates related alerts by the business service they affect. Instead of managing numerous disconnected alerts during incidents, your team receives a single organized view focused on the impacted business service. This approach accelerates the identification of broken services and streamlines response efforts.

    Show full answer Show less

    How the Grouping Works

    Each alert is linked to a Configuration Item (CI), such as a server or network device. The system traces the CI upward through its application and infrastructure dependencies to identify the top-level Business Service affected, known as the Top Service. All alerts that trace back to the same Top Service are grouped together, regardless of their physical or network distance within the infrastructure. This grouping provides a comprehensive view of the overall impact on critical services, similar to a NOC dashboard that prioritizes service-level issues over individual alerts.

    When to Use Shared Impacted Services Grouping

    ServiceNow offers two alert grouping methods:

    • CMDB-based alert grouping: Best suited for simpler, flatter service topologies where CIs are within four hops of each other. It groups alerts based on direct CI relationships in the CMDB.
    • Shared Impacted Services grouping: Ideal for complex or deep service topologies common in large organizations, where business services are supported by long chains of applications and infrastructure components. This method groups all alerts linked to the same Top Service, regardless of how many hops away the CIs are.

    Use Shared Impacted Services grouping when your service trees have multiple topology levels to ensure no related alert is missed in the group, providing a complete picture of service impact in complex environments.

    The Shared impacted services alert grouping automatically gathers related alerts under the business service they affect. When your IT environment generates multiple alerts at once, instead of facing a flood of disconnected notifications, your team gets one focused, organized view — making it faster to spot what is broken and act.

    The Shared impacted services alert grouping feature solves this by automatically gathering related alerts into one place. It looks at each alert, figures out which business service is ultimately affected — for example, Online Payments or HR Portal — and groups all alerts that point to the same service together.

    How the grouping decision is made

    Every alert is linked to a Configuration Item (CI) — the specific piece of infrastructure where the problem was detected, such as a web server or a network switch. That CI is part of a larger chain: it supports an application, which in turn supports a Business Service.

    When Event Management receives an alert, it traces that chain upward to find the most important Business Service (identified by business criticality) the CI belongs to. This is called the Top Service. Any other alerts that trace back to the same Top Service are automatically pulled into the same group.

    Think of it like a network operations center (NOC) dashboard: instead of investigating each blinking alert one by one, the operator first identifies the most critical service that is down — that is the Top Service. Every alert tied to that Top Service is already grouped together, giving an instant picture of the full impact.

    With CMDB-based alert grouping, alerts are only grouped if the CIs involved are closely connected in the topology — there is a limit on how far apart they can be. Shared Impacted Services grouping works differently: it does not care about the distance between CIs at all. If two alerts trace back to the same Top Service, they are grouped — regardless of how far apart the underlying CIs are in the infrastructure.

    When to use this feature

    ServiceNow Event Management offers two approaches to alert grouping, and choosing the right one depends on how your service topology is structured.

    CMDB-based alert grouping works well when your infrastructure is relatively flat — where CIs supporting a service are no more than four topology hops away from each other. Within that boundary, it groups alerts based on the relationships between CIs in the CMDB.

    Shared Impacted Services grouping is the better choice when your service topology is deep or complex. In large organizations, a Business Service often sits at the top of a long chain — with applications, middleware, databases, and infrastructure components layered beneath it across many levels. If a CI is five, six, or more hops away from the top of that chain, CMDB-based grouping will not include its alerts in the group. Shared Impacted Services grouping has no such restriction — as long as an alert's CI traces back to the same Top Service, it is grouped, no matter how deep in the topology that CI sits.

    In short: if your service trees are shallow, either approach works. If your service trees are deep and span many topology levels, use Shared Impacted Services grouping to ensure no related alert is left out.

    For details on creating a group automation, see Create Group automation.