Apply suggestions from code review

Co-authored-by: Yechiel Levin <[email protected]>
Co-authored-by: Batami Gold <[email protected]>

Author: 3 people

articles/sentinel/microsoft-sentinel-defender-portal.md

@@ -57,7 +57,7 @@ This section covers the Microsoft Sentinel capabilities or integrations that are
 | Entities: Add entities to threat intelligence from incidents | Azure portal only | This functionality is unavailable in the Defender portal. <Br><br>For more information, see [Add entity to threat indicators](add-entity-to-threat-intelligence.md). |
 | Fusion: Advanced multistage attack detection | Azure portal only  | The Fusion analytics rule, which creates incidents based on alert correlations made by the Fusion correlation engine, is disabled when you onboard Microsoft Sentinel to the Defender portal. <br><br>The Defender portal uses Microsoft Defender XDR's incident-creation and correlation functionalities to replace those of the Fusion engine. <br><br>For more information, see [Advanced multistage attack detection in Microsoft Sentinel](fusion.md) |
 | Incidents: Adding alerts to incidents /<br>Removing alerts from incidents | Defender portal only | After onboarding Microsoft Sentinel to the Defender portal, you can no longer add alerts to, or remove alerts from, incidents in the Azure portal. <br><br>You can remove an alert from an incident in the Defender portal, but only by linking the alert to another incident (existing or new). |
-| <a name="5min"></a>Incidents: Creation | After onboarding to the Defender portal: Incidents are created by the correlation engine in the Microsoft Defender portal. | Incidents created in the Defender portal for alerts generated by Microsoft Sentinel have <b>Incident `providerName`</b> = <b>Microsoft  XDR</b>. <br><br>Any active Microsoft security incident creation rules are deactivated to avoid creating duplicate incidents. The incident creation settings in other types of analytics rules remain as they were, but those settings are implemented in the Defender portal, not in Microsoft Sentinel.<br><br>It may take up to 5 minutes for Microsoft Defender incidents to show in Microsoft Sentinel. This doesn't affect features provided directly by Microsoft Defender, such as automatic attack disruption.<br><br>For more information, see the following articles: <br>- [Incidents and alerts in the Microsoft Defender portal](/defender-xdr/incidents-overview) <br>- [Alert correlation and incident merging in the Microsoft Defender portal](/defender-xdr/alerts-incidents-correlation) |
+| <a name="5min"></a>Incidents: Creation | After onboarding to the Defender portal: Incidents are created by the correlation engine in the Microsoft Defender portal. | Incidents created in the Defender portal for alerts generated by Microsoft Sentinel have <b>Incident `providerName`</b> = <b>`Microsoft XDR`</b>. <br><br>Any active Microsoft security incident creation rules are deactivated to avoid creating duplicate incidents. The incident creation settings in other types of analytics rules remain as they were, but those settings are implemented in the Defender portal, not in Microsoft Sentinel.<br><br>It may take up to 5 minutes for Microsoft Defender incidents to show in Microsoft Sentinel. This doesn't affect features provided directly by Microsoft Defender, such as automatic attack disruption.<br><br>For more information, see the following articles: <br>- [Incidents and alerts in the Microsoft Defender portal](/defender-xdr/incidents-overview) <br>- [Alert correlation and incident merging in the Microsoft Defender portal](/defender-xdr/alerts-incidents-correlation) |
 | Incidents: Editing comments | Azure portal only | After onboarding Microsoft Sentinel to the Defender portal, you can add comments to incidents in either portal, but you can't edit existing comments. <br><br>Edits made to comments in the Azure portal don't synchronize to the Defender portal. |
 | Incidents: Programmatic and manual creation of incidents | Azure portal only  | 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). |
 | Incidents: Reopening closed incidents | Azure portal only  | In the Defender portal, you can't set alert grouping in Microsoft Sentinel analytics rules to reopen closed incidents if new alerts are added. <br>Closed incidents aren't reopened in this case, and new alerts trigger new incidents. |
@@ -140,10 +140,10 @@ The following table lists the changes in navigation between the Azure and Defend
 
 ### API responses
 
-The unified experience introduces changes to incidents and alerts APIs. It supports API calls based on the Microsoft Graph REST API v1.0, which can be used for automation related to alerts, incidents, and advanced hunting. 
+The unified experience in the Defender portal introduces notable changes to incidents and alerts from APIs. It supports API calls based on the [Microsoft Graph REST API v1.0](/graph/api/resources/security-api-overview?view=graph-rest-1.0), which can be used for automation related to alerts, incidents, advanced hunting, and more.
 
-The Microsoft Sentinel’s API continues to support actions against Microsoft Sentinel resources, like analytics rules, automation rules. For interacting with unified incidents and alerts, we recommended to use the Microsoft Graph REST API.
-If you are using the SecurityInsights API to interact with Microsoft Sentinel incidents, you may need to update your automation conditions and trigger criteria due to changes in the response body. The following fields are important in the response body of the API:
+The [Microsoft Sentinel API](/rest/api/securityinsights/api-versions) continues to support actions against Microsoft Sentinel resources, like analytics rules, automation rules and more.   For interacting with unified incidents and alerts, we recommend that you use the Microsoft Graph REST API.
+If you're using the Microsoft Sentinel `SecurityInsights` API to interact with Microsoft Sentinel incidents, you may need to update your automation conditions and trigger criteria due to changes in the response body. The following fields are important in the response snippets:
 
 + `alertProductNames`: The source that triggered the detection 
 + `incidentUrl`: The direct URL to the incident in the Microsoft Sentinel portal
@@ -155,13 +155,12 @@ After transitioning to the unified experience, the following sections are added
 
 When using an HTTP GET command for a specific unified incident with the Microsoft Graph REST API, the body response has the following differences:
 
-+ The `incidentWebUrl` field provides the direct link to the incident, which can be used to synchronize this information with a ticketing system like ServiceNow. 
-+ If the response doesn't contain the `alertProductNames` array, you can retrieve it by updating the initial HTTP GET command. Add `?$expand=alerts` after the GET command, for example `https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts`
++ The `incidentWebUrl` field provides a direct link to the incident, which can be used to synchronize this information with a third-party ticketing system like ServiceNow. 
++ If the response doesn't contain the `alertProductNames` array, you can retrieve it by updating the initial HTTP GET command to add `?$expand=alerts` after the GET command. For example: `https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts`
 
 The following new fields have been added to the response body:
 + `serviceSource` : The service or product that created the alert 
 + `detectionSource` : Detection technology or sensor that identified the notable component or activity 
-+ `productName`  : The name of the product that published this alert. 
 
 
 ## Related content