Shared impacted services alert grouping

  • Release version: Australia
  • Updated August 11, 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 consolidates multiple related alerts under the single business service they affect. This provides your IT team with a focused, organized view of issues, enabling faster identification and resolution of service disruptions.

    Show full answer Show less

    How Grouping Works

    Each alert is associated with a Configuration Item (CI), such as a server or network device. ServiceNow traces the CI upward through the service hierarchy—from the CI to the application it supports, then to the overarching Business Service. The highest priority Business Service, called the Top Service, is identified based on business criticality. All alerts linked to the same Top Service are automatically grouped together, regardless of the physical or logical distance between their underlying CIs.

    This approach differs from traditional CMDB-based alert grouping, which groups alerts only if CIs are within a limited number of topology hops (typically up to four). Shared impacted services alert grouping removes this limitation and groups alerts even when CIs are deep within complex service topologies.

    When to Use Shared Impacted Services Alert Grouping

    • Shallow service topologies: Both CMDB-based and Shared Impacted Services grouping are effective when CIs supporting a service are close in the topology (within about four hops).
    • Deep or complex service topologies: Use Shared Impacted Services grouping when your service hierarchy includes many layers, such as applications, middleware, databases, and infrastructure components spanning multiple levels. This ensures all related alerts tied to the same Top Service are grouped, even if their CIs are far apart in the topology.

    This feature helps prevent alert overload and provides a comprehensive view of the impact on critical business services, improving incident detection and response efficiency.

    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.