Explore step-by-step how Microsoft Sentinel can turn alerts into manageable incidents and how Defender XDR integration changes incident flow
The security operations workflow changes when alerts are converted into actionable work items. This guide explains how Microsoft Sentinel ingests alerts from Microsoft security services, how you can enable automatic incident creation, and what changes when you integrate Microsoft Defender XDR.
In this article, alert refers to a raw detection generated by a connected security product, while incident denotes the consolidated case that an analyst triages. You will learn prerequisites, recommended approaches such as custom detections, and how to preserve filtering and automation after integration.
Before making changes, ensure your environment has the necessary connectors and solutions installed from the Content hub. The examples below assume you have installed and configured the appropriate data connector for each Microsoft security product. Note the important recommendation that custom detections are now the preferred method to implement new detection logic across Microsoft Sentinel and Microsoft Defender XDR, offering lower ingestion cost and seamless mapping of entities.
Enable incident creation directly from data connectors
One straightforward option is to turn on incident generation inside a solution’s connector. When you open a given data connector in Microsoft Sentinel, look for the Create incidents – Recommended setting and switch it to Enable. This action activates a built-in analytics rule that converts incoming alert records from that security service into incidents automatically. After enabling, you can fine-tune the analytics rule under the Analytics blade to adjust thresholds, severity filters, or automation triggers. Remember that alerts initially land in the SecurityAlert table and incidents appear in the securityIncident table.
When the connector option is not visible
In some tenants the connector UI does not show the incident creation toggle. That usually means your workspace is already onboarded into the Defender portal or you’ve activated the Defender XDR connector. In that situation, incidents are generated by the Defender correlation engine instead of Sentinel’s internal incident creation rules. Do not enable duplicate paths: instead, manage filtering and automation from the Defender portal or rely on the bi-directional sync described below.
Create Microsoft incident creation rules from templates or from scratch
Microsoft Sentinel also supplies prebuilt templates to create targeted incident creation rules for each Microsoft security product. From Analytics choose the Rule templates tab, filter for the Microsoft security type, and pick the template matching your source (for example, Microsoft Defender for Endpoint or Microsoft Defender for Identity). Templates are editable: set the Filter by severity or match specific text in alert names to control which alerts become incidents. Alternatively, you can create a Microsoft incident creation rule from scratch to combine alerts across multiple sources with custom filters and automation.
Integrating Microsoft Defender XDR with Microsoft Sentinel
Integrating Microsoft Defender XDR changes how alerts and incidents flow. If a workspace was onboarded to the Defender portal after July 1, 2026 and the user had Owner or User Access Administrator permission, the workspace is automatically available in the Defender portal. In that setup, Sentinel data appears directly inside the Defender experience and Defender XDR becomes the primary incident engine. If you prefer to operate from the Azure portal, enable the Microsoft Defender XDR connector in Sentinel so that Defender-generated incidents and advanced hunting events stream into Sentinel and remain synchronized.
Portal choices and synchronization
Both integration methods aim to keep incidents synchronized and rich with context. With Defender XDR connected, incidents brought into Sentinel include associated alerts, entities, and links that support triage. Under normal conditions, Defender XDR incidents show up in the Sentinel UI and API within about five minutes, though full ingestion into the securityIncident table can take a few more minutes. Bi-directional sync preserves status, owner, and closing reason between the portals so analysts can work where they prefer without losing updates.
Data behavior, costs, and rule implications
Alerts and incidents that flow through the Defender XDR connector populate Sentinel tables at no ingestion charge; however, other Defender component data such as advanced hunting tables are billed. When Defender XDR is in use, Sentinel’s Microsoft incident creation rules for integrated products are disabled to prevent duplicates. To retain filtering and suppression capabilities, configure alert tuning inside the Defender portal or use automation rules to close or suppress incidents you do not want. Also note that incident titles are assigned by the Defender correlation engine, so automation that relies on incident name should instead use other properties as conditions.
By following these patterns—installing the right Content hub solutions, choosing connector-level incident generation or building template rules, and carefully deciding how to integrate Defender XDR—you can ensure reliable incident creation, efficient triage, and synchronized investigations across portals. Use custom detections where possible for cost-effective, real-time coverage and keep automation rules resilient to changes in incident naming and flow.
