Lesson 27 — Grouping Alerts into Incidents

Learning objectives

After completing this lesson, you should understand how alert grouping shapes the incidents analysts receive.

• Explain the difference between events, alerts and incidents.
• Configure a grouping time window.
• Understand the available grouping criteria.
• Use entities and details to keep unrelated activity apart.
• Recognise the risks of grouping too broadly or too narrowly.

The investigation

A scheduled rule runs every few minutes and repeatedly detects suspicious sign-ins for alex@contoso.com.

Six alerts are generated. If each alert becomes its own incident, the SOC may see six tickets for what is really one continuing investigation.

Event grouping is different

Event grouping controls how query results from one rule execution become alerts.

A scheduled rule can group all returned events into one alert or generate an alert for each returned result.

Alert grouping comes afterwards

Alert grouping controls how alerts generated by the analytics rule are placed into incidents.

Think of it as two separate decisions: events → alerts, then alerts → incidents.

Enable incident creation

Scheduled analytics rules can be configured to create incidents from the alerts they generate.

If incident creation is disabled, the rule can still produce alerts, but those alerts will not create incidents through that rule's incident settings.

Enable alert grouping

Under the rule's incident settings, alert grouping can be enabled when you want similar or recurring alerts from the rule placed into a single incident.

The grouping settings then decide which alerts belong together.

Option 1 — all entities match

Alerts can be grouped when they share identical values for all mapped entities defined by the analytics rule.

Microsoft identifies this as the recommended grouping option for scheduled analytics rules.

Why entity mapping now matters again

Lesson 25 was not just about making an alert look better.

If incident grouping relies on matching entities, the quality of your account, IP, host and other entity mappings directly affects which alerts Sentinel considers related.

Option 2 — group every alert from the rule

You can group all alerts triggered by the analytics rule into one incident within the configured grouping window.

This is broad grouping. Alerts do not need matching entities to be placed together.

Broad grouping can hide separation

If one rule detects activity across many unrelated users or hosts, grouping everything together can create a noisy incident containing several unrelated investigations.

The fact that alerts came from the same rule does not automatically mean they belong to the same attack story.

Lesson 26 now becomes operational

Custom details are not only useful for displaying investigation context.

Selected custom details can also participate in incident grouping, allowing a value such as application or another rule-specific detail to help determine whether alerts belong together.

Up to 150 alerts per incident

Microsoft Sentinel can group up to 150 alerts into a single incident through these rule settings.

If more than 150 alerts need to be grouped, another incident is created for the excess alerts.

Common mistake — group everything

A rule fires against twenty unrelated accounts and every alert is grouped simply because it came from the same rule.

The analyst receives one giant incident containing several separate stories.

Common mistake — group nothing

The same account generates repeated related alerts but every alert becomes a separate incident.

The SOC queue grows while analysts repeatedly open what is essentially the same investigation.

Common mistake — poor entity mapping

If your grouping logic depends on entities but the rule maps them poorly, related alerts may not match as expected.

Incident design therefore starts back at the query and entity mapping stages.

Common mistake — window too long

A very long grouping window can keep adding activity to an old investigation when a fresh incident would provide a clearer operational boundary.

Choose the window according to the behaviour being detected, not simply the maximum available setting.

Best practices

• Decide what one investigation should represent.
• Separate event grouping from incident alert grouping.
• Use meaningful entity mappings before relying on entity-based grouping.
• Choose a grouping window that matches the behaviour being detected.
• Use selected details when they provide a meaningful investigation boundary.
• Test the incident queue, not only whether the rule fires.

Agent Foskett takeaway

A detection rule is not finished when it creates an alert. The resulting incidents must also make operational sense.

Good grouping turns repeated related alerts into a coherent investigation without accidentally combining unrelated activity.