L10. Analytics Rules: Scheduled, NRT and Fusion
Visual workflow edition
Worked example, diagrams and a question with time to think. Synthetic American-English narration; examples are fictional. Reviewed October 2026.
Read the video transcript
Your query finds the suspicious events you expected. Can you switch on a detection and walk away? Not yet. The rule's schedule, time window, threshold, entity mapping, and incident behavior all change the outcome. Let's turn one query into a detection you can test and explain.
Scheduled rules run queries on a configured cadence and lookback window. Near-real-time rules serve supported low-latency scenarios with their own constraints. Sentinel also offers other detection types and templates. Choose based on the data and behavior you need. A faster label does not guarantee better coverage, and rule capabilities can change over time.
In a fictional example, an event occurs before noon but arrives several minutes later. If your detection window excludes it by the time the rule evaluates, the query may miss it. Test the relationship between event time, arrival delay, and evaluation. Also check whether overlapping windows could generate duplicate alerts for the same activity.
Decide what result should trigger an alert and why. Map the relevant entities correctly so an analyst can investigate the user, host, or address. Provide useful alert details without overstating certainty. A high count may be suspicious, but it may also reflect a legitimate batch process. The threshold needs business and data context.
Use controlled data or approved test activity to verify an expected detection. Then test a benign case that should not trigger. Inspect the alert and incident output, including grouping and repeated runs. Document what the rule can and cannot detect. A successful query preview is not a complete test of the configured rule.
Your query preview finds the test event, but no incident appears after the rule runs. What should you inspect next? Pause and think beyond the query text.
Inspect the rule's evaluation, trigger conditions, grouping, and incident settings. Confirm that the relevant data was available at execution time. The lesson is to validate the whole detection path. Keep a small test case and expected result, then repeat it after meaningful changes. Next, we'll use incident evidence to guide investigation.
Course outlineLesson 10 of 18
Analytics rules are the detection engine in Microsoft Sentinel. This lesson covers rule types, scheduled query configuration, near-real-time rules, Fusion ML-based detections, and rule tuning strategies for the SC-200 exam.
Analytics Rule Types
Microsoft Sentinel includes the following analytics rule types and specialized templates:
| Rule Type | Detection Latency | Use Case |
|---|---|---|
| Scheduled | Configurable query schedule and lookback | Custom detections with KQL queries |
| NRT (Near-Real-Time) | ~1 minute | Low-latency detection for critical threats |
| Fusion | Varies | ML-based multi-stage attack detection |
| Microsoft security | Depends on source | Creates incidents from Microsoft security alerts where supported |
| Anomaly | Baseline-dependent | Records unusual behavior in the Anomalies table; does not generate its own alerts |
Scheduled Analytics Rules
Scheduled rules run KQL queries at defined intervals. Key configuration parameters:
- Query: The KQL detection logic
- Run frequency: How often the rule executes (e.g., every 5 minutes, every hour)
- Lookup period: How far back the query looks (e.g., last 5 minutes, last 1 hour)
- Alert threshold: Minimum results to trigger an alert
- Entity mapping: Map query results to Sentinel entities (Account, Host, IP, URL, File)
- Alert grouping: Group alerts into a single incident or create separate incidents
Example scheduled rule:
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "50053"
| where Location != "US"
| summarize AttemptCount = count() by UserPrincipalName, IPAddress, Location
| where AttemptCount > 5Near-Real-Time (NRT) Rules
NRT rules run every minute with a 1-minute lookup window. They are designed for detections that require minimal delay:
- No configurable frequency (fixed at ~1 minute)
- Support most KQL operators (with some limitations)
- Can reference multiple tables and run across multiple workspaces
- Uses ingestion time, with a built-in two-minute delay; a one-minute schedule does not mean immediate detection
Use NRT rules for high-priority detections like ransomware encryption patterns or critical system changes. Exam tip: Choose scheduled rules when you need configurable frequency and lookback. NRT rules use a fixed one-minute ingestion window. Verify current query support instead of assuming older single-table or single-workspace restrictions.
Fusion Rules
Fusion uses machine learning to detect multi-stage attacks by correlating low-fidelity alerts from multiple sources. For example:
- Suspicious sign-in from an unusual location (Entra ID)
- Inbox rule creation forwarding emails (Office 365)
- Mass file download from SharePoint (Cloud Apps)
Individually, these alerts might not warrant investigation. Fusion correlates them into a high-confidence incident.
Fusion detects scenarios like:
- Ransomware deployment following credential compromise
- Data exfiltration after lateral movement
- Crypto mining after initial access
Fusion rules are enabled by default and cannot be customized (you cannot modify the ML logic).
Entity Mapping
Entity mapping links query results to Sentinel entity types:
- Account: UserPrincipalName, SID, AADUserId
- Host: HostName, FQDN, IP Address
- IP: Address
- URL: Url
- File: Name, Directory, Hash
- Mailbox: MailboxPrimaryAddress
Proper entity mapping enables:
- Investigation graph visualization
- Entity pages with aggregated information
- Entity behavior analytics (UEBA)
- Automated response actions targeting the entity
Alert Grouping
Alert grouping controls how alerts from the same rule are combined into incidents:
- Group all alerts into a single incident: Reduces noise when the same rule fires repeatedly
- Group alerts by selected entities: Creates separate incidents per entity (e.g., per user or per host)
- Limit group to a time window: Limit how far apart alerts can be to join an incident; this does not automatically close the incident
Tuning and Suppression
To reduce false positives:
- Add exclusion conditions to the KQL query
- Use analytics rule suppression (pause the rule after it fires for a specified duration)
- Adjust alert thresholds
- Refine entity mapping for better correlation
References
- ✓Scheduled rules have configurable frequency and lookup periods. The lookup must be >= the frequency to avoid gaps.
- ✓NRT rules run every minute using ingestion time and support multiple tables and workspaces.
- ✓Fusion uses ML to correlate low-fidelity alerts from multiple sources into high-confidence multi-stage attack incidents.
- ✓Entity mapping connects query results to Sentinel entities (Account, Host, IP, URL, File, Mailbox).
- ✓Alert grouping by entity creates separate incidents per user or host instead of a single combined incident.
- ✓Fusion rules are enabled by default and their ML logic cannot be customized.
1. A detection must run hourly with a configurable lookback window. Which analytics rule type should you choose?
2. A scheduled analytics rule runs every 10 minutes with a lookup period of 5 minutes. What is the risk?
3. Which Sentinel analytics rule type uses machine learning to correlate alerts from multiple Microsoft products into multi-stage attack incidents?
Keep learning
Use the knowledge check above to test your understanding. You can browse every lesson without signing in; opening another lesson does not mark this one complete.
Next lesson: Sentinel Incidents: Investigation and Evidence →