| title | include |
|---|---|
| ms.date | 08/25/2025 |
| ms.topic | include |
| Functionality | Description |
|---|---|
| Automation rules with alert triggers | In the Defender portal, automation rules with alert triggers act only on Microsoft Sentinel alerts. For more information, see Alert create trigger. |
| Automation rules with incident triggers | In both the Azure portal and the Defender portal, the Incident provider condition property is removed, as all incidents have Microsoft XDR as the incident provider (the value in the ProviderName field). At that point, any existing automation rules run on both Microsoft Sentinel and Microsoft Defender XDR incidents, including those where the Incident provider condition is set to only Microsoft Sentinel or Microsoft 365 Defender. However, automation rules that specify a specific analytics rule name run only on incidents that contain alerts that were created by the specified analytics rule. This means that you can define the Analytic rule name condition property to an analytics rule that exists only in Microsoft Sentinel to limit your rule to run on incidents only in Microsoft Sentinel. Also, after onboarding to the Defender portal, the SecurityIncident table no longer includes a Description field. Therefore: - If you're using this Description field as a condition for an automation rule with an incident creation trigger, that automation rule won't work after onboarding to the Defender portal. In such cases, make sure to update the configuration appropriately. For more information, see Incident trigger conditions. - If you have an integration configured with an external ticketing system, like ServiceNow, the incident description will be missing. |
| Latency in playbook triggers | It might take up to 5 minutes for Microsoft Defender incidents to appear in Microsoft Sentinel. If this delay is present, playbook triggering is delayed too. |
| Changes to existing incident names | The Defender portal uses a unique engine to correlate incidents and alerts. When onboarding your workspace to the Defender portal, existing incident names might be changed if the correlation is applied. To ensure that your automation rules always run correctly, we therefore recommend that you avoid using incident titles as condition criteria in your automation rules, and suggest instead to use the name of any analytics rule that created alerts included in the incident, and tags if more specificity is required. |
| Updated by field | For more information, see Incident update trigger. |
| Creating automation rules directly from an incident | Creating automation rules directly from an incident is supported only in the Azure portal. If you're working in the Defender portal, create your automation rules from scratch from the Automation page. |
| Microsoft incident creation rules | Microsoft incident creation rules aren't supported in the Defender portal. For more information, see Microsoft Defender XDR incidents and Microsoft incident creation rules. |
| Running automation rules from the Defender portal | It might take up to 10 minutes from the time that an alert is triggered and an incident is created or updated in the Defender portal to when an automation rule is run. This time lag is because the incident is created in the Defender portal and then forwarded to Microsoft Sentinel for the automation rule. |
| Active playbooks tab | After onboarding to the Defender portal, by default the Active playbooks tab shows a predefined filter with onboarded workspace's subscription. In the Azure portal, add data for other subscriptions using the subscription filter. For more information, see Create and customize Microsoft Sentinel playbooks from templates. |
| Running playbooks manually on demand | The following procedures aren't currently supported in the Defender portal: |
| Running playbooks on incidents requires Microsoft Sentinel sync | If you try to run a playbook on an incident from the Defender portal and see the message "Can't access data related to this action. Refresh the screen in a few minutes." message, this means that the incident isn't yet synchronized to Microsoft Sentinel. Refresh the incident page after the incident is synchronized to run the playbook successfully. |
| Incidents: Adding alerts to incidents / Removing alerts from incidents |
Since adding alerts to, or removing alerts from incidents isn't supported after onboarding your workspace to the Defender portal, these actions are also not supported from within playbooks. For more information, see Understand how alerts are correlated and incidents are merged in the Defender portal. |
| Microsoft Defender XDR integration in multiple workspaces | If you've integrated XDR data with more than one workspace in a single tenant, the data will now only be ingested into the primary workspace in the Defender portal. Transfer automation rules to the relevant workspace to keep them running. |
| Automation and the Correlation engine | The correlation engine may combine alerts from multiple signals into a single incident, which could result in automation receiving data you didn’t anticipate. We recommend reviewing your automation rules to ensure you're seeing the expected results. |