Merge pull request #233406 from MicrosoftDocs/main

4/04 PM Publish

Author: huypub

.openpublishing.redirection.healthcare-apis.json

@@ -590,7 +590,11 @@
           "redirect_document_id": false
       },
       {   "source_path_from_root": "/articles/healthcare-apis/iot/data-flow.md",
-          "redirect_url": "/azure/healthcare-apis/iot/understand-service",
+          "redirect_url": "/azure/healthcare-apis/iot/overview-of-device-message-processing-stages",
+          "redirect_document_id": false
+      },
+      {   "source_path_from_root": "/articles/healthcare-apis/iot/understand-service.md",
+          "redirect_url": "/azure/healthcare-apis/iot/overview-of-device-message-processing-stages",
           "redirect_document_id": false
       },
       {   "source_path_from_root": "/articles/healthcare-apis/iot/how-to-use-device-mappings.md",

articles/active-directory/app-provisioning/how-provisioning-works.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 04/03/2023
+ms.date: 04/04/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -221,18 +221,18 @@ The table describes how you can configure deprovisioning actions with the Azure
 
 |Scenario|How to configure in Azure AD|
 |--|--|
-|If a user is unassigned from an app, soft-deleted in Azure AD, or blocked from sign-in, do nothing.|Remove isSoftDeleted from the attribute mappings and / or set the [skip out of scope deletions](skip-out-of-scope-deletions.md) property to true.|
-|If a user is unassigned from an app, soft-deleted in Azure AD, or blocked from sign-in, set a specific attribute to true / false.|Map isSoftDeleted to the attribute that you would like to set to false.|
-|When a user is disabled in Azure AD, unassigned from an app, soft-deleted in Azure AD, or blocked from sign-in, send a DELETE request to the target application.|This is currently supported for a limited set of gallery applications where the functionality is required. It's not configurable by customers.|
-|When a user is deleted in Azure AD, do nothing in the target application.|Ensure that "Delete" isn't selected as one of the target object actions in the [attribute configuration experience](skip-out-of-scope-deletions.md).|
-|When a user is deleted in Azure AD, set the value of an attribute in the target application.|Not supported.|
-|When a user is deleted in Azure AD, delete the user in the target application|This is supported. Ensure that Delete is selected as one of the target object actions in the [attribute configuration experience](skip-out-of-scope-deletions.md).|
+|A user is unassigned from an app, soft-deleted in Azure AD, or blocked from sign-in. You don't want anything to be done.|Remove `isSoftDeleted` from the attribute mappings and / or set the [skip out of scope deletions](skip-out-of-scope-deletions.md) property to true.|
+|A user is unassigned from an app, soft-deleted in Azure AD, or blocked from sign-in. You want to set a specific attribute to `true` or `false`.|Map `isSoftDeleted` to the attribute that you would like to set to false.|
+|A user is disabled in Azure AD, unassigned from an app, soft-deleted in Azure AD, or blocked from sign-in. You want to send a DELETE request to the target application.|This is currently supported for a limited set of gallery applications where the functionality is required. It's not configurable by customers.|
+|A user is deleted in Azure AD. You don't want anything done in the target application.|Ensure that "Delete" isn't selected as one of the target object actions in the [attribute configuration experience](skip-out-of-scope-deletions.md).|
+|A user is deleted in Azure AD. You want to set the value of an attribute in the target application.|Not supported.|
+|A user is deleted in Azure AD. You want to delete the user in the target application|Ensure that Delete is selected as one of the target object actions in the [attribute configuration experience](skip-out-of-scope-deletions.md).|
 
 **Known limitations**
 
-* If a user that was previously managed by the provisioning service is unassigned from an app, or from a group assigned to an app then a disable request is sent. At that point, the user isn't managed by the service and a delete request isn't sent when the user is deleted from the directory.
+* When a user or group is unassigned from an app and no longer managed with the provisioning service, a disable request is sent. At that point, the service doesn't manage the user and a delete request isn't sent when the user is deleted from the directory.
 * Provisioning a user that is disabled in Azure AD isn't supported. They must be active in Azure AD before they're provisioned.
-* When a user goes from soft-deleted to active, the Azure AD provisioning service will activate the user in the target app, but won't automatically restore the group memberships. The target application should maintain the group memberships for the user in inactive state. If the target application doesn't support this, you can restart provisioning to update the group memberships. 
+* When a user goes from soft-deleted to active, the Azure AD provisioning service activates the user in the target app, but doesn't automatically restore the group memberships. The target application should maintain the group memberships for the user in inactive state. If the target application doesn't support maintaining the inactive state, you can restart provisioning to update the group memberships. 
 
 **Recommendation**
 

articles/active-directory/conditional-access/media/workload-identity/conditional-access-workload-identity-risk-policy.png

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: workload-identities
 ms.topic: how-to
-ms.date: 01/05/2023
+ms.date: 04/04/2023
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -29,7 +29,7 @@ These differences make workload identities harder to manage and put them at high
 
 > [!IMPORTANT]
 > Workload Identities Premium licenses are required to create or modify Conditional Access policies scoped to service principals. 
-> In directories without appropriate licenses, existing Conditional Access policies for workload identities will continue to function, but can't be modified. For more information see [Microsoft Entra Workload Identities](https://www.microsoft.com/security/business/identity-access/microsoft-entra-workload-identities#office-StandaloneSKU-k3hubfz).  
+> In directories without appropriate licenses, existing Conditional Access policies for workload identities will continue to function, but can't be modified. For more information, see [Microsoft Entra Workload Identities](https://www.microsoft.com/security/business/identity-access/microsoft-entra-workload-identities#office-StandaloneSKU-k3hubfz).  
 
 > [!NOTE]
 > Policy can be applied to single tenant service principals that have been registered in your tenant. Third party SaaS and multi-tenanted apps are out of scope. Managed identities are not covered by policy. 
@@ -49,7 +49,7 @@ Create a location based Conditional Access policy that applies to service princi
 1. Under **Assignments**, select **Users or workload identities**.
    1. Under **What does this policy apply to?**, select **Workload identities**.
    1. Under **Include**, choose **Select service principals**, and select the appropriate service principals from the list.
-1. Under **Cloud apps or actions**, select **All cloud apps**. The policy will apply only when a service principal requests a token.
+1. Under **Cloud apps or actions**, select **All cloud apps**. The policy applies only when a service principal requests a token.
 1. Under **Conditions** > **Locations**, include **Any location** and exclude **Selected locations** where you want to allow access.
 1. Under **Grant**, **Block access** is the only available option. Access is blocked when a token request is made from outside the allowed range.
 1. Your policy can be saved in **Report-only** mode, allowing administrators to estimate the effects, or policy is enforced by turning policy **On**.
@@ -68,7 +68,7 @@ Create a risk-based Conditional Access policy that applies to service principals
 1. Under **Assignments**, select **Users or workload identities**.
    1. Under **What does this policy apply to?**, select **Workload identities**.
    1. Under **Include**, choose **Select service principals**, and select the appropriate service principals from the list.
-1. Under **Cloud apps or actions**, select **All cloud apps**. The policy will apply only when a service principal requests a token.
+1. Under **Cloud apps or actions**, select **All cloud apps**. The policy applies only when a service principal requests a token.
 1. Under **Conditions** > **Service principal risk**
    1. Set the **Configure** toggle to **Yes**.
    1. Select the levels of risk where you want this policy to trigger.