Microsoft Sentinel - Analytics Rules and Incidents

Summary

Analytics rules turn a query you trust into a detection that keeps running when nobody is watching. Each rule raises alerts, and alerts become incidents that analysts triage and close. This article covers choosing a rule type, building a scheduled rule, how alerts group into incidents, and how automation rules handle the routine work.

A Query Nobody Reran

Using A.M Finances Group as our business example. Last week, an analyst ran a query and found a departing loan officer who had downloaded hundreds of files from SharePoint in one afternoon. The query worked, but nobody ran it again until someone remembered. The security manager asked a fair question: can Microsoft Sentinel tell us when it happens again?

That is the job of an analytics rule: a saved query plus instructions for how often to run it, how far back to look, what counts as a hit, and what to do with one. Get those right and the team stops depending on memory.

Pick the Right Rule Type

The rule type shapes everything that follows. Scheduled rules are the workhorse. They run a Kusto query at an interval you choose and raise an alert when results cross your threshold. Near-real-time, or NRT, rules run every minute for detections where minutes matter, and you can have up to 50 enabled. Anomaly rules use machine learning to build a baseline and write what falls outside it to the Anomalies table. They do not raise alerts on their own.

Before writing anything from scratch, look in the Content hub, where Microsoft and solution vendors publish rule templates. Two points matter in the Defender portal. Microsoft security rules and the Fusion rule are not used once a workspace is onboarded, because the Defender XDR correlation engine creates and correlates incidents instead. And Microsoft now calls custom detections the best way to create new rules across Sentinel and Defender XDR, so check whether one fits before you build.

Build a Scheduled Rule

In the Defender portal, open Microsoft Sentinel, then Configuration, then Analytics, and select Create, then Scheduled query rule. The wizard moves through general details, rule logic, incident settings, automated response, and review. The detection lives in the rule logic stage. Paste a tested query, then set how often it runs and how far back it looks. Both accept 5 minutes to 14 days, and the interval cannot be longer than the lookback, or the rule would leave gaps. The query must also return the TimeGenerated column, which the rule uses to apply the lookback.

Two settings deserve care. Entity mapping tells Sentinel which query fields are accounts, hosts, or IP addresses, up to 10 in all, and investigators and the correlation engine rely on them later. Event grouping decides whether a run produces one summary alert or one alert per result, up to 150 per run. Before you enable the rule, select Test with current data, which simulates the last 50 runs. At A.M Finances Group, the analyst counted downloads for each account and address every hour, flagged anything over 200, mapped both fields, and saw one hit in 50 runs. That was quiet enough to enable.

From Alerts to Incidents

Each hit becomes an alert, and by default each alert creates an incident. That is where noise starts. If the same account trips the rule three hours in a row, three tickets is the wrong answer. Alert grouping, in the rule's incident settings, combines related alerts into one incident. You can group when all entities match, which Microsoft recommends, group everything the rule raises, or group when selected entities and details match. One incident holds up to 150 alerts, and the grouping window runs from 5 minutes to 7 days, with 5 hours as the default.

The Defender portal adds a twist. Once your workspace is onboarded, the Defender XDR correlation engine builds all incidents, including those from your Sentinel rules. The grouping settings still appear, but the engine decides how alerts group and merge, and incident names can change. Closed incidents are not reopened, so a new matching alert starts a new incident. Careful entity mapping is the best way to help the engine connect your alerts. At A.M Finances Group, three hourly hits on one account arrived as a single incident with a timeline.

Triage, Then Automate

Incidents appear in the Defender portal under Investigation and response, then Incidents and alerts. Microsoft recommends the newer incident cases experience, now in preview. In the standard view, an incident starts as Active, moves to In progress while someone works it, and ends as Resolved with a classification: true positive, informational or expected activity, or false positive. Those classifications help tune detections over time.

Automation rules handle the routine part. They run when an incident is created or updated, or when an alert is created, then act: assign an owner, change status or severity, add a tag or task, or run a playbook. Rules run in order. Microsoft advises against using the incident title as a condition, because correlation can rename incidents. Use the analytics rule name or a tag instead. At A.M Finances Group, an automation rule tagged the download incident, raised its severity, and assigned it to the Tier 1 queue before an analyst opened it. Plan around two dates as well. The older alert automation in the rule wizard has been deprecated since March 2026, and after March 31, 2027, Microsoft Sentinel is supported only in the Defender portal.

Conclusion

A rule turns a query you trust into a detection that works when nobody is looking. Choose the type first, set the schedule and threshold with care, test with current data, and map your entities. Let grouping turn many alerts into one story, and let automation rules assign and tag it. A.M Finances Group went from a query somebody had to remember to an incident that arrived ready to work.