Most analysts think…
Most people treat Microsoft Sentinel as 'an alert list you scroll through'. That misses the entire investigation layer — and costs hours per incident.
Sentinel is a case management + investigation platform. The incident queue groups correlated alerts, the investigation graph draws the entity relationship map so you can see blast radius without querying, entity pages give pre-built timelines and insights on every user, host or IP, automation rules triage the easy cases before a human touches them, and incident tasks let multiple analysts divide work on a single case. Understanding the full stack is what separates a junior SOC analyst from a senior one in an interview — and in a real breach.
① The incident queue — severity, status and first triage
The incident queue is the landing page for SOC work in Microsoft Sentinel. It shows every incident created from correlated alerts, with the most critical at the top. Each row shows the incident name, severity (High / Medium / Low / Informational), status (New / Active / Closed), owner, number of alerts, affected entities, and MITRE ATT&CK tactics.
Analysts use the filter bar to narrow by severity, status, product, tactic, or assigned owner. Clicking an incident opens the incident details panel — a side pane showing a summary, the alert list, entity list, comments, tasks, and a direct link to the investigation graph. Status and severity can be changed right from the panel without navigating away.
A well-disciplined SOC closes every incident with a classification: True Positive, Benign Positive, False Positive or Undetermined. These feedback signals feed Sentinel's tuning and reporting dashboards over time.
Never close a Sentinel incident without setting the classification (True Positive, False Positive, Benign Positive, Undetermined). These labels feed Sentinel's detection-quality metrics and help you justify tuning analytics rules in a review meeting.
Which four severity levels exist for a Sentinel incident?
② Entities & entity pages — users, hosts, IPs in context
Every Sentinel alert maps its raw log fields to entities — structured objects such as accounts, hosts, IP addresses, files, processes, mailboxes and URLs. Entities are the connective tissue that lets Sentinel correlate alerts across different data sources into a single incident: two alerts from different analytics rules that mention the same user account are fused into one incident because they share an entity.
Selecting any entity inside an incident opens its entity page, a three-tab view: Info (account or host properties), Timeline (all alerts and bookmarks involving this entity in the last 30 days by default), and Insights (pre-built queries that surface anomalies — off-hours logins, first-time geolocation, impossible travel, privilege escalation history). Entity pages can also be reached from the investigation graph and from the Entity Behavior menu.
Why this matters in triage
A single glance at the entity timeline tells you whether this user has appeared in two incidents this month or fifty. That context decides whether you escalate immediately or treat it as an isolated misconfiguration — without writing a single KQL query yourself.
The central SOC view: all correlated incidents with severity, status, owner, alert count, entity count and MITRE tactics — filterable and sortable.
Three tabs per entity: Info (properties), Timeline (30-day activity history), and Insights (pre-built anomaly queries) — no KQL required for first-pass context.
A canvas rendering entities, alerts, and bookmarks as nodes with relationship edges — expands on click to reveal blast radius without writing a query.
A trigger-and-action rule on incident creation or update: set severity, status, owner, tags, inject tasks, or fire a Logic App playbook — all before a human opens the ticket.
What does the Timeline tab on an entity page show?
③ The investigation graph — visualising blast radius
The investigation graph opens from the incident details panel and renders a canvas where every entity, alert, and bookmark involved in the incident is a node, with edges showing how they relate. A compromised account node might link to a host, a malicious IP, a process spawn, and a lateral movement alert — all visible at once without writing a query.
Analysts can expand nodes: clicking a host node surfaces related alerts, related accounts, and related IPs from the same incident and from the entity's historical activity. This reveals the blast radius — how far the threat has spread across the environment. Each node is clickable and opens the entity page side panel without leaving the graph.
Bookmarks (tagged query results) appear as nodes too. An analyst who ran a hunting query, found suspicious process execution, and saved a bookmark can see that bookmark sitting next to the alert that triggered the incident — the graph makes the causal chain visible. The investigation graph is particularly valued in interview discussions because it demonstrates understanding that Sentinel is a relationship database, not just an alert list.
The investigation graph shows entity relationships inside an incident (alerts, bookmarks, accounts, hosts, IPs) — not a physical network topology. Nodes represent data objects Sentinel knows about from logs, not live network devices. Expanding a node adds related entities from workspace data, not from network discovery.
▶ Watch a phishing alert become a closed, classified incident
Step through the full investigation lifecycle. Press Play for the clean path, then Break it to see the classic automation failure.
An analyst wants to see how far a compromised host is connected to other entities without writing a KQL query. Best action?
④ Automation rules, incident tasks & bookmarks
Automation rules fire on incident creation or update and can: change severity, change status, assign an owner, add a tag, run a playbook, or create incident tasks — all before a human touches the incident. A classic first rule is if severity = Informational AND no High entity risk → set status = Closed (Benign Positive). This drains the noise floor so analysts focus on real work.
Incident tasks are a checklist attached to an incident. They can be created manually inside the incident or injected automatically by an automation rule. A task might read: 'Confirm host isolation in Defender' or 'Gather user manager approval'. Multi-analyst teams assign tasks to individuals; the incident shows a completed/total task count so the case manager can see progress at a glance.
Bookmarks — raw evidence to formal case
During a threat-hunting session, an analyst runs a KQL query in Logs, spots suspicious PowerShell execution, and clicks Add bookmark. The bookmark saves the row, the query, the time range, entities, and MITRE tags. From the Bookmarks blade the analyst can then Investigate (open the graph) or Add to existing incident — promoting a raw hunting find into the formal case without re-running an analytics rule.
Divya at a Mumbai fintech SOC faces this
The Sentinel incident queue has 400 open incidents, 80% rated Informational. Analysts are overwhelmed and missing real High-severity events buried in the noise.
No automation rules exist. Every incident — regardless of severity — stays open in the queue at status New until a human manually triages it.
Open Automation ▸ Automation rules: zero rules defined. The analytics rules generating Informational incidents have no auto-close logic. High incidents are not assigned or tagged.
Sentinel ▸ Automation ▸ Automation rules ▸ + CreateCreate rule 1: IF severity = Informational AND no High-risk entity → set status = Closed, classification = Benign Positive. Create rule 2: IF severity = High → assign owner = SOC-L2 group, inject a five-task checklist, add tag PRIORITY. Re-check queue in 24 hours.
Queue drops to fewer than 80 incidents; all remaining items are Medium or above; High incidents show owner and tasks. Analysts now work real cases only.
After creating an automation rule, open a test incident that matches the trigger conditions. Check the incident comments — Sentinel logs an automatic comment each time an automation rule fires, listing the rule name and the actions taken. No comment means the rule conditions did not match.
A SOC wants to ensure every new High-severity incident gets a standard five-step task checklist automatically. Best approach?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the single fastest way to understand the blast radius of a compromised account in Sentinel? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Incident queue
- The main SOC view in Sentinel listing all open incidents with severity, status, owner, alert count, and MITRE tactics — filterable and sortable.
- Severity
- A four-level label assigned to a Sentinel incident: High, Medium, Low, or Informational. Set by the analytics rule or changed by an automation rule.
- Entity
- A structured object extracted from an alert — account, host, IP, file, process, mailbox, or URL — that Sentinel uses to correlate alerts into incidents.
- Entity page
- A three-tab view (Info, Timeline, Insights) that shows properties, 30-day activity history, and pre-built anomaly queries for a specific entity — no KQL required.
- Investigation graph
- A visual canvas in Sentinel that renders entities, alerts, and bookmarks as nodes with relationship edges, letting analysts see blast radius by expanding nodes.
- Automation rule
- A trigger-and-action configuration in Sentinel that fires on incident creation or update: sets severity, status, owner, tags, injects tasks, or runs a playbook.
- Incident task
- A checklist item attached to a Sentinel incident to coordinate multi-analyst investigation steps; created manually or injected by an automation rule.
- Bookmark
- A saved KQL query result (with entities, time range, and MITRE tags) that can be promoted from the Bookmarks blade into a formal incident as a graph node.
- Alert grouping
- An analytics-rule setting that fuses multiple alert matches sharing an entity within a time window into a single incident instead of creating separate tickets.
- Classification
- The closing label on a Sentinel incident: True Positive, False Positive, Benign Positive, or Undetermined — required for detection-quality reporting.
📚 Sources
- Microsoft Learn — Investigate Microsoft Sentinel incidents in depth in the Azure portal. learn.microsoft.com/en-us/azure/sentinel/investigate-incidents
- Microsoft Learn — Automate threat response in Microsoft Sentinel with automation rules. learn.microsoft.com/en-us/azure/sentinel/automate-incident-handling-with-automation-rules
- Microsoft Learn — Microsoft Sentinel entity pages. learn.microsoft.com/en-us/azure/sentinel/entity-pages
- Microsoft Learn — Use bookmarks for investigations in Microsoft Sentinel. learn.microsoft.com/en-us/azure/sentinel/bookmarks
- Microsoft Learn — Incident navigation and triage in the Azure portal. learn.microsoft.com/en-us/azure/sentinel/incident-navigate-triage
- Microsoft Learn — Create incident tasks in Microsoft Sentinel using automation rules. learn.microsoft.com/en-us/azure/sentinel/create-tasks-automation-rule
What's next?
Got incident investigation covered? Next, explore Microsoft Sentinel analytics rules — scheduled queries, NRT rules and fusion detections — to understand how raw log events become the alerts that feed the incident queue.