Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into erpubpeering

Author: duongau

.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/develop/tutorial-v2-android.md

@@ -59,7 +59,7 @@ Refer to the [configuration documentation](./msal-configuration.md) for more inf
 
 Set `"shared_device_mode_supported"` to `true` in your MSAL configuration file.
 
-You may not be planning to support multiple-account mode. That could be if you're not using a shared device, and the user can sign into the app with more than one account at the same time. If so, set `"account_mode"` to `"SINGLE"`. This guarantees that your app will always get `ISingleAccountPublicClientApplication`, and significantly simplifies your MSAL integration. The default value of `"account_mode"` is `"MULTIPLE"`, so it is important to change this value in the config file if you're using `"single account"` mode.
+You may not be planning to support multiple-account mode. That could be if you're not using a shared device, and the user can sign into the app with more than one account at the same time. If so, set `"account_mode"` to `"SINGLE"`. This guarantees that your app will always get `ISingleAccountPublicClientApplication`, and significantly simplifies your MSAL integration. The default value of `"account_mode"` is `"MULTIPLE"`, so it's important to change this value in the config file if you're using `"single account"` mode.
 
 Here's an example of the auth_config.json file included in the **app**>**main**>**res**>**raw** directory of the sample app:
 
@@ -85,7 +85,7 @@ Here's an example of the auth_config.json file included in the **app**>**main**>
 
 ### Detect shared-device mode
 
-Shared-device mode allows you to configure Android devices to be shared by multiple employees, while providing Microsoft Identity backed management of the device. Employees can sign in to their devices and access customer information quickly. When they are finished with their shift or task, they will be able to sign-out of all apps on the shared device with a single click and the device will be immediately ready for the next employee to use.
+Shared-device mode allows you to configure Android devices to be shared by multiple employees, while providing Microsoft Identity backed management of the device. Employees can sign in to their devices and access customer information quickly. When they're finished with their shift or task, they'll be able to sign-out of all apps on the shared device with a single click and the device will be immediately ready for the next employee to use.
 
 Use `isSharedDevice()` to determine if an app is running on a device that is in shared-device mode. Your app could use this flag to determine if it should modify UX accordingly.
 
@@ -122,7 +122,7 @@ PublicClientApplication.create(this.getApplicationCOntext(),
 
 If you're writing an app that will only be used for first-line workers on a shared device, we recommend you write your app to only support single-account mode. This includes most applications that are task focused such as medical records apps, invoice apps, and most line-of-business apps. This will simplify your development as many features of the SDK won't need to be accommodated.
 
-If your app supports multiple accounts as well as shared device mode, you must perform a type check and cast to the appropriate interface as shown below.
+If your app supports multiple accounts and shared device mode, you must perform a type check and cast to the appropriate interface as shown below.
 
 ```java
 private IPublicClientApplication mApplication;
@@ -207,9 +207,9 @@ private void onSignOutClicked()
 
 ### Receive broadcast to detect global sign out initiated from other applications
 
-To receive the account change broadcast, you'll need to register a broadcast receiver.  It’s recommended to register your broadcast receiver via the [Context-registered receivers](https://developer.android.com/guide/components/broadcasts#context-registered-receivers).
+To receive the account change broadcast, you need to register a broadcast receiver.  It’s recommended to register your broadcast receiver via the [Context-registered receivers](https://developer.android.com/guide/components/broadcasts#context-registered-receivers).
 
-When an account change broadcast is received, immediately [get the signed in user and determine if a user has changed on the device](#get-the-signed-in-user-and-determine-if-a-user-has-changed-on-the-device). If a change is detected, initiate data cleanup for previously signed-in account. It is recommended to properly stop any operations and do data cleanup.
+When an account change broadcast is received, immediately [get the signed in user and determine if a user has changed on the device](#get-the-signed-in-user-and-determine-if-a-user-has-changed-on-the-device). If a change is detected, initiate data cleanup for previously signed-in account. It's recommended to properly stop any operations and do data cleanup.
 
 The following code snippet shows how you could register a broadcast receiver.
 
@@ -238,14 +238,14 @@ The following steps describe setting up your application in the Azure portal and
 
 First, register your application within your organizational tenant. Then provide these values below in auth_config.json in order for your application to run correctly.
 
-For information on how to do this, refer to [Register your application](./tutorial-v2-android.md#register-your-application).
+For information on how to do this, refer to [Register your application](./tutorial-v2-android.md#register-your-application-with-azure-ad).
 
 > [!NOTE]
 > When you register your app, please use the quickstart guide on the left-hand side and then select **Android**. This will lead you to a page where you'll be asked to provide the **Package Name** and **Signature Hash** for your app. These are very important to ensure your app configuration will work. You'll then receive a configuration object that you can use for your app that you'll cut and paste into your auth_config.json file.
 
 :::image type="content" source="media/tutorial-v2-shared-device-mode/register-app.png" alt-text="Configure your Android app page in Azure portal quickstart":::
 
-You should select **Make this change for me** and then provide the values the quickstart asks for in the Azure portal. When that's done, we will generate all the configuration files you need.
+You should select **Make this change for me** and then provide the values the quickstart asks for in the Azure portal. When that's done, we'll generate all the configuration files you need.
 
 :::image type="content" source="media/tutorial-v2-shared-device-mode/config-info.png" alt-text="Configure your project page in Azure portal quickstart":::
 
@@ -257,7 +257,7 @@ For testing purposes, set up the following in your tenant: at least two employee
 
 ### Download the Authenticator App
 
-Download the Microsoft Authenticator App from the Google Play store. If you already have the app downloaded, ensure that it is the latest version.
+Download the Microsoft Authenticator App from the Google Play store. If you already have the app downloaded, ensure that it's the latest version.
 
 ### Authenticator app settings & registering the device in the cloud
 
@@ -293,7 +293,7 @@ Once you've put a device in shared-mode, it becomes known to your organization a
 
 ## Running the sample app
 
-The Sample Application is a simple app that will call the Graph API of your organization. On first run you'll be prompted to consent as the application is new to your employee account.
+The Sample Application is a simple app that will call the Graph API of your organization. On first run, you'll be prompted to consent as the application is new to your employee account.
 
 :::image type="content" source="media/tutorial-v2-shared-device-mode/run-app-permissions-requested.png" alt-text="Application configuration info screen":::
 

articles/active-directory/develop/tutorial-v2-shared-device-mode.md

@@ -21,40 +21,49 @@ Lifecycle Workflows allow you to create workflows that can be triggered based on
 
 ## Prerequisite Logic App roles required for integration with the custom task extension
 
-When linking your Azure Logic App with the custom task extension task, there are certain permissions that must be completed before the link can be established. 
+When you link your Azure Logic App with the custom task extension task, there are certain prerequisites that must be completed before the link can be established. 
 
-The roles on the Azure Logic App, which allows it to be compatible with the custom task extension, are as follows:
+To create a Logic App, you must have:
+
+- A valid Azure subscription
+- A compatible resource group where the Logic App is located
+
+> [!NOTE]
+> The resource group needs permissions to create, update, and read the Logic App while the custom extension is being created. 
+
+The roles on the Azure Logic App required with the custom task extension, are as follows:
 
 - **Logic App contributor**
 - **Contributor**
 - **Owner**
 
 > [!NOTE]
-> The **Logic App Operator** role alone will not make an Azure Logic App compatible with the custom task extension. For more information on the required **Logic App contributor** role, see: [Logic App Contributor](../../role-based-access-control/built-in-roles.md#logic-app-contributor).
+> The **Logic App Operator** role alone will not work with the custom task extension. For more information on the required **Logic App contributor** role, see: [Logic App Contributor](../../role-based-access-control/built-in-roles.md#logic-app-contributor).
 
 ## Custom task extension deployment scenarios
 
 When creating custom task extensions, the scenarios for how it interacts with Lifecycle Workflows can be one of two ways:
 
  :::image type="content" source="media/lifecycle-workflow-extensibility/task-extension-deployment-scenarios.png" alt-text="Screenshot of custom task deployment scenarios.":::
 
-- **Launch and continue** - The Azure Logic App is started, and the following task execution immediately continues with no response expected from the Azure Logic App. This scenario is best suited if the Lifecycle workflow doesn't require any feedback (including status) from the Azure Logic App. With this scenario, as long as the workflow is started successfully, the workflow is viewed as a success.
+- **Launch and continue** - The Azure Logic App is started, and the following task execution immediately continues with no response expected from the Azure Logic App. This scenario is best suited if the Lifecycle workflow doesn't require any feedback (including status) from the Azure Logic App. If the Logic App is started successfully, the Lifecycle Workflow task is considered a success.
 - **Launch and wait** - The Azure Logic App is started, and the following task's execution waits on the response from the Logic App. You enter a time duration for how long the custom task extension should wait for a response from the Azure Logic App. If no response is received within a customer defined duration window, the task is considered failed.
  :::image type="content" source="media/lifecycle-workflow-extensibility/custom-task-launch-wait.png" alt-text="Screenshot of custom task launch and wait task choice." lightbox="media/lifecycle-workflow-extensibility/custom-task-launch-wait.png":::
 
+> [!NOTE]
+> You can also deploy a custom task that calls to a third party system. To learn more about this call, see: [taskProcessingResult: resume](/graph/api/identitygovernance-taskprocessingresult-resume).
+
 ## Response authorization
 
-When creating a custom task extension that waits for a response from the Logic App, you're able to define which applications can send a response
+When you create a custom task extension that waits for a response from the Logic App, you're able to define which applications can send a response
 
 :::image type="content" source="media/lifecycle-workflow-extensibility/launch-wait-options.png" alt-text="Screenshot of custom task extension launch and wait options.":::
 
 Response authorization can be utilized in one of the following ways:
 
-- **System-assigned managed identity (Default)** - Enables and utilizes the Logic Apps system-assigned managed identity. For more information on this, see: [Authenticate access to Azure resources with managed identities in Azure Logic Apps](/azure/logic-apps/create-managed-service-identity)
-- **No authorization** - Grants no authorization to the Logic App. You're responsible for assigning an application permission, or role assignment.
-- **Existing application** - You can choose an existing application to respond.
-
-
+- **System-assigned managed identity (Default)** - With this choice you Enable and utilize the Logic Apps system-assigned managed identity. For more information, see: [Authenticate access to Azure resources with managed identities in Azure Logic Apps](/azure/logic-apps/create-managed-service-identity)
+- **No authorization** -  With this choice you assign a Logic App or third party application an application permission (LifecycleWorkflows.ReadWrite.All), or role assignment (Lifecycle Workflows Administrator). This choice doesn't follow least privilege access as outlined in Azure Active Directory best practices. For more information on best practices for roles, see: [Best Practices for Azure AD roles](/azure/active-directory/roles/best-practices).
+- **Existing application** - With this choice you're able to choose an existing application to respond. You are able to choose applications that are user-assigned or regular applications. For more information on managed identity types, see: [Managed identity types](../managed-identities-azure-resources/overview.md#managed-identity-types).
 
 ## Custom task extension integration with Azure Logic Apps high-level steps
 
@@ -69,19 +78,6 @@ The high-level steps for the Azure Logic Apps integration are as follows:
 - **Create a lifecycle workflow customTaskExtension which holds necessary information about the Azure Logic App**: Creating a custom task extension that references the configured Azure Logic App.
 - **Update or create a Lifecycle workflow with the “Run a custom task extension” task, referencing your created customTaskExtension**: Adding the newly created custom task extension to a new workflow, or updating the information to an existing workflow.
 
-## Logic App parameters used by the custom task
-
-When creating a custom task extension from the Azure portal, you're able to create a Logic App, or link it to an existing one.
-:::image type="content" source="media/lifecycle-workflow-extensibility/custom-task-logic-app.png" alt-text="Screenshot of a custom task create logic app selection screen."::: 
-
-The following information is supplied to the custom task from the Logic App:
-
-- Subscription
-- Resource group
-- Logic App name
-
-
-For a guide on supplying this information to a custom task extension via Microsoft Graph, see: [Configure a Logic App for Lifecycle Workflow use](configure-logic-app-lifecycle-workflows.md).
 
 ## Next steps