api changes

Author: batamig

articles/sentinel/automation/automation.md

@@ -56,7 +56,7 @@ After onboarding your Microsoft Sentinel workspace to the Defender portal, note
 | Functionality | Description  |
 | --------- | --------- |
 | **Automation rules with alert triggers** | In the Defender portal, automation rules with alert triggers act only on Microsoft Sentinel alerts. <br><br>For more information, see [Alert create trigger](../automate-incident-handling-with-automation-rules.md#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 Defender XDR* as the incident provider (the value in the *ProviderName* field). <br><br>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*. <br><br>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. <br><br>For more information, see [Incident trigger conditions](../automate-incident-handling-with-automation-rules.md#conditions). |
+| **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). <br><br>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*. <br><br>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. <br><br>For more information, see [Incident trigger conditions](../automate-incident-handling-with-automation-rules.md#conditions). |
 |**Latency in playbook triggers** | [It might take up to 5 minutes](../move-to-defender.md#5min) 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** | <li>After onboarding your workspace, the **Updated by** field has a [new set of supported values](../automate-incident-handling-with-automation-rules.md#incident-update-trigger), which no longer include *Microsoft 365 Defender*. In existing automation rules, *Microsoft 365 Defender* is replaced by a value of *Other* after onboarding your workspace. <br><br><li>If multiple changes are made to the same incident in a 5-10 minute period, a single update is sent to Microsoft Sentinel, with only the most recent change. <br><br>For more information, see [Incident update trigger](../automate-incident-handling-with-automation-rules.md#incident-update-trigger). |

articles/sentinel/create-analytics-rules.md

@@ -179,7 +179,7 @@ In the **Incident settings** tab, choose whether Microsoft Sentinel turns alerts
      >
      > - In this scenario, incidents are created by Microsoft Defender XDR, not by Microsoft Sentinel.
      > - These incidents appear in the incidents queue in both the Azure and Defender portals.
-     > - In the Azure portal, new incidents are displayed with "Microsoft Defender XDR" as the **incident provider name**.
+     > - In the Azure portal, new incidents are displayed with "Microsoft XDR" as the **incident provider name**.
 
    - If you want a single incident to be created from a group of alerts, instead of one for every single alert, see the next step.
 

articles/sentinel/create-manage-use-automation-rules.md

@@ -118,7 +118,7 @@ Use the options in the **Conditions** area to define conditions for your automat
 
         If you selected one of the incident triggers and you want the automation rule to take effect only on incidents created in Microsoft Sentinel, or alternatively, only on those imported from Microsoft Defender XDR, specify the source in the **If Incident provider equals** condition. (This condition is displayed only if an incident trigger is selected.)
 
-    - **Analytic rule name**: For all trigger types, if you want the automation rule to take effect only on certain analytics rules, specify which ones by modifying the **If Analytics rule name contains** condition. (This condition isn't displayed if Microsoft Defender XDR is selected as the incident provider.)
+    - **Analytic rule name**: For all trigger types, if you want the automation rule to take effect only on certain analytics rules, specify which ones by modifying the **If Analytics rule name contains** condition. (This condition isn't displayed if Microsoft  XDR is selected as the incident provider.)
 
     Then, continue by selecting one of the following operators:
 

articles/sentinel/move-to-defender.md

@@ -142,6 +142,8 @@ The following table lists fields that are important in the response snippets, an
 |Link to the incident     |    `incidentUrl`, links to the incident in Microsoft Sentinel in the Azure portal     |  `providerIncidentUrl`, links to the incident in the Defender portal       |
 |The name of the alert provider     |   `providerName`      |   `providerName` always shows as `Microsoft XDR`      |
 
+<!--is this microsoft xdr or microsoft defender xdr? check with ed-->
+
 The following table lists all elements that are added or changed in the Microsoft Sentinel `SecurityInsights` API after onboarding your workspace to the Defender portal:
 
 | Field     | Change Description     |
@@ -195,7 +197,7 @@ tasks - still true?-->
 |---------|---------|
 |**Delay just after onboarding your workspace**  <a name="5min"></a>   | It may take up to 5 minutes for Microsoft Defender incidents to fully integrate with Microsoft Sentinel. This doesn't affect features provided directly by Microsoft Defender, such as automatic attack disruption.        |
 |**Security incident creation rules**     | Any active [Microsoft security incident creation rules](create-incidents-from-alerts.md) are deactivated to avoid creating duplicate incidents. The incident creation settings in other types of analytics rules remain as they were, and are configurable in the Defender portal.   |
-|**Incident provider name**     | In the Defender portal, the **Incident provider name** is always Microsoft Defender XDR.        |
+|**Incident provider name**     | In the Defender portal, the **Incident provider name** is always Microsoft XDR.        |
 |**Adding / removing alerts from incidents**     | Adding or removing Microsoft Sentinel alerts to or from incidents is supported only in the Defender portal. To remove an alert from an incident in the Defender portal, you must [add the alert to another incident](/defender-xdr/move-alert-to-another-incident).        |
 |**Editing comments**     |  Add comments to incidents in either the Defender or Azure portal, but editing existing comments isn't supported in the Defender portal. Edits made to comments in the Azure portal aren't synchronized to the Defender portal.       |
 |**Programmatic and manual creation of incidents**     |    Incidents created in Microsoft Sentinel through the API, by a Logic App playbook, or manually from the Azure portal, aren't synchronized to the Defender portal. These incidents are still supported in the Azure portal and the API. See [Create your own incidents manually in Microsoft Sentinel](create-incident-manually.md).     |

articles/sentinel/workspaces-defender-portal.md

@@ -81,7 +81,7 @@ How incident changes sync between the Azure portal and the Defender portal depen
 
 |Workspace |Sync behavior  |
 |---------|---------|
-|Primary     |  For Microsoft Sentinel in the Azure portal, Defender XDR incidents appear in **Threat management** > **Incidents** with the incident provider name **Microsoft Defender XDR**. Any changes you make to the status, closing reason, or assignment of a Defender XDR incident in either the Azure or Defender portal, update in the other's incidents queue.  For more information, see [Working with Microsoft Defender XDR incidents in Microsoft Sentinel and bi-directional sync](microsoft-365-defender-sentinel-integration.md#working-with-microsoft-defender-xdr-incidents-in-microsoft-sentinel-and-bi-directional-sync).|
+|Primary     |  For Microsoft Sentinel in the Azure portal, Defender XDR incidents appear in **Threat management** > **Incidents** with the incident provider name **Microsoft XDR**. Any changes you make to the status, closing reason, or assignment of a Defender XDR incident in either the Azure or Defender portal, update in the other's incidents queue.  For more information, see [Working with Microsoft Defender XDR incidents in Microsoft Sentinel and bi-directional sync](microsoft-365-defender-sentinel-integration.md#working-with-microsoft-defender-xdr-incidents-in-microsoft-sentinel-and-bi-directional-sync).|
 |Secondary   | All alerts and incidents that you create for a secondary workspace are synced between that workspace in the Azure and Defender portals.   Data in a workspace is only synced to the workspace in the other portal.      |
 
 ## Related content