fix merge conflict in recover-storage-account

Author: ggailey777

README.md

@@ -10,7 +10,7 @@ Contributing to open source is more than just providing updates, it's also about
 
 You've decided to contribute, that's great! To contribute to the documentation, you need a few tools.
 
-#### Github
+#### GitHub
 
 Contributing to the documentation requires a GitHub account. If you don't have an account, follow the instructions for [GitHub account setup](https://learn.microsoft.com/contribute/get-started-setup-github) from our contributor guide.
 

articles/active-directory-b2c/add-ropc-policy.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 09/12/2021
+ms.date: 12/16/2022
 ms.custom: project-no-code
 ms.author: kengaderdus
 ms.subservice: B2C
@@ -27,19 +27,19 @@ In Azure Active Directory B2C (Azure AD B2C), the resource owner password creden
 In Azure Active Directory B2C (Azure AD B2C), the following options are supported:
 
 - **Native Client**: User interaction during authentication happens when code runs on a user-side device. The device can be a mobile application that's running in a native operating system, such as Android and iOS.
-- **Public client flow**: Only user credentials, gathered by an application, are sent in the API call. The credentials of the application are not sent.
+- **Public client flow**: Only user credentials, gathered by an application, are sent in the API call. The credentials of the application aren't sent.
 - **Add new claims**: The ID token contents can be changed to add new claims.
 
-The following flows are not supported:
+The following flows aren't supported:
 
 - **Server-to-server**: The identity protection system needs a reliable IP address gathered from the caller (the native client) as part of the interaction. In a server-side API call, only the server’s IP address is used. If a dynamic threshold of failed authentications is exceeded, the identity protection system may identify a repeated IP address as an attacker.
-- **Confidential client flow**: The application client ID is validated, but the application secret is not validated.
+- **Confidential client flow**: The application client ID is validated, but the application secret isn't validated.
 
 When using the ROPC flow, consider the following:
 
-- ROPC doesn’t work when there is any interruption to the authentication flow that needs user interaction. For example, when a password has expired or needs to be changed, [multifactor authentication](multi-factor-authentication.md) is required, or when more information needs to be collected during sign-in (for example, user consent).
+- ROPC doesn’t work when there's any interruption to the authentication flow that needs user interaction. For example, when a password has expired or needs to be changed, [multifactor authentication](multi-factor-authentication.md) is required, or when more information needs to be collected during sign-in (for example, user consent).
 - ROPC supports local accounts only. Users can’t sign in with [federated identity providers](add-identity-provider.md) like Microsoft, Google+, Twitter, AD-FS, or Facebook.
-- [Session Management](session-behavior.md), including [keep me signed-in (KMSI)](session-behavior.md#enable-keep-me-signed-in-kmsi), is not applicable.
+- [Session Management](session-behavior.md), including [keep me signed-in (KMSI)](session-behavior.md#enable-keep-me-signed-in-kmsi), isn't applicable.
 
 
 ## Register an application
@@ -59,7 +59,7 @@ When using the ROPC flow, consider the following:
 1. Select **Sign in using resource owner password credentials (ROPC)**.
 1. Under **Version**, make sure **Preview** is selected, and then select **Create**.
 1. Provide a name for the user flow, such as *ROPC_Auth*.
-1. Under **Application claims**, click **Show more**.
+1. Under **Application claims**, select **Show more**.
 1. Select the application claims that you need for your application, such as Display Name, Email Address, and Identity Provider.
 1. Select **OK**, and then select **Create**.
 
@@ -256,7 +256,7 @@ If you've not done so, learn about custom policy starter pack in [Get started wi
 
 7. On the **Custom Policies** page in your Azure AD B2C tenant, select **Upload Policy**.
 8. Enable **Overwrite the policy if it exists**, and then browse to and select the *TrustFrameworkExtensions.xml* file.
-9. Click **Upload**.
+9. Select **Upload**.
 
 ## Create a relying party file
 
@@ -277,7 +277,7 @@ Next, update the relying party file that initiates the user journey that you cre
 
 5. On the **Custom Policies** page in your Azure AD B2C tenant, select **Upload Policy**.
 6. Enable **Overwrite the policy if it exists**, and then browse to and select the *ROPC_Auth.xml* file.
-7. Click **Upload**.
+7. Select **Upload**.
 
 
 ::: zone-end
@@ -367,10 +367,10 @@ A successful response looks like the following example:
 
 ## Troubleshooting
 
-### The provided application is not configured to allow the 'OAuth' Implicit flow
+### The provided application isn't configured to allow the 'OAuth' Implicit flow
 
-* **Symptom** - You run the ROPC flow, and get the following message: *AADB2C90057: The provided application is not configured to allow the 'OAuth' Implicit flow*.
-* **Possible causes** - The implicit flow is not allowed for your application.
+* **Symptom** - You run the ROPC flow, and get the following message: *AADB2C90057: The provided application isn't configured to allow the 'OAuth' Implicit flow*.
+* **Possible causes** - The implicit flow isn't allowed for your application.
 * **Resolution**: When creating your [app registration](#register-an-application) in Azure AD B2C, you need to manually edit the application manifest and set the value of the `oauth2AllowImplicitFlow` property to `true`. After you configure the `oauth2AllowImplicitFlow` property, it can take a few minutes (typically no more than five) for the change to take affect. 
 
 ## Use a native SDK or App-Auth

articles/active-directory-b2c/add-sign-up-and-sign-in-policy.md

@@ -79,8 +79,8 @@ The sign-up and sign-in user flow handles both sign-up and sign-in experiences w
 1. Follow the steps to [handle the flow for "Forgot your password?"](add-password-reset-policy.md?pivots=b2c-user-flow.md#self-service-password-reset-recommended) within the sign-up or sign-in policy.
 
 
-### Re-order the sign up form
-Learn [how to re-order user flow input fields for local accounts](customize-ui.md#re-order-input-fields-in-the-sign-up-form)
+### Rearrange the sign up form
+Learn [how to rearrange user flow input fields for local accounts](customize-ui.md#rearrange-input-fields-in-the-sign-up-form)
 
 ### Test the user flow
 

articles/active-directory-b2c/api-connectors-overview.md

@@ -1,11 +1,11 @@
 ---
 title: About API connectors in Azure AD B2C
-description: Use Azure Active Directory (Azure AD) API connectors to customize and extend your user flows by using REST APIs or outbound webhooks to external identity data sources. 
+description: Use Azure Active Directory (Azure AD) API connectors to customize and extend your user flows and custom policies by using REST APIs or outbound webhooks to external identity data sources. 
 services: active-directory-b2c
 ms.service: active-directory
 ms.subservice: B2C
 ms.topic: how-to
-ms.date: 11/02/2021
+ms.date: 12/16/2022
 
 ms.author: kengaderdus
 author: kengaderdus
@@ -14,7 +14,7 @@ ms.custom: "it-pro"
 zone_pivot_groups: b2c-policy-type
 ---
 
-# Use API connectors to customize and extend sign-up user flows with external identity data sources 
+# Use API connectors to customize and extend sign-up user flows and custom policies with external identity data sources 
 
 [!INCLUDE [active-directory-b2c-choose-user-flow-or-custom-policy](../../includes/active-directory-b2c-choose-user-flow-or-custom-policy.md)]
 
@@ -27,7 +27,7 @@ As a developer or IT administrator, you can use API connectors to integrate your
 - **Validate user input data**. Validate against malformed or invalid user data. For example, you can validate user-provided data against existing data in an external data store or list of permitted values. If invalid, you can ask a user to provide valid data or block the user from continuing the sign-up flow.
 - **Verify user identity**. Use an identity verification service or external identity data sources to add an extra level of security to account creation decisions.
 - **Integrate with a custom approval workflow**. Connect to a custom approval system for managing and limiting account creation.
-- **Augment tokens with attributes from external sources**. Enrich tokens with attributes about the user from sources external to Azure AD B2C such as cloud systems, custom user stores, custom permission systems, legacy identity services, and more.
+- **Augment tokens with attributes from external sources**. Enrich tokens with attributes about the user from sources that are external to Azure AD B2C such as cloud systems, custom user stores, custom permission systems, legacy identity services, and more.
 - **Overwrite user attributes**. Reformat or assign a value to an attribute collected from the user. For example, if a user enters the first name in all lowercase or all uppercase letters, you can format the name with only the first letter capitalized. 
 - **Run custom business logic**. You can trigger downstream events in your cloud systems to send push notifications, update corporate databases, manage permissions, audit databases, and perform other custom actions.
 
@@ -43,7 +43,7 @@ There are three places in a user flow where you can enable an API connector:
 
 ### After federating with an identity provider during sign-up
 
-An API connector at this step in the sign-up process is invoked immediately after the user authenticates with an identity provider (like Google, Facebook, & Azure AD). This step precedes the ***attribute collection page***, which is the form presented to the user to collect user attributes. This step is not invoked if a user is registering with a local account. The following are examples of API connector scenarios you might enable at this step:
+An API connector at this step in the sign-up process is invoked immediately after the user authenticates with an identity provider (like Google, Facebook, & Azure AD). This step precedes the ***attribute collection page***, which is the form presented to the user to collect user attributes. This step isn't invoked if a user is registering with a local account. The following are examples of API connector scenarios you might enable at this step:
 
 - Use the email or federated identity that the user provided to look up claims in an existing system. Return these claims from the existing system, pre-fill the attribute collection page, and make them available to return in the token.
 - Implement an allow or blocklist based on social identity.
@@ -74,15 +74,15 @@ The Identity Experience Framework, which underlies Azure Active Directory B2C (A
 
 Using Azure AD B2C, you can add your own business logic to a user journey by calling your own RESTful service. The Identity Experience Framework can send and receive data from your RESTful service to exchange claims. For example, you can:
 
-- **Use external identity data source to validate user input data**. For example, you can verify that the email address provided by the user exists in your customer's database, and if not, present an error. You can as well think of API connectors as a way of supporting outbound webhooks because the call is made when an event occurs e.g. a sign up.
+- **Use external identity data source to validate user input data**. For example, you can verify that the email address provided by the user exists in your customer's database, and if not, present an error. You can as well think of API connectors as a way of supporting outbound webhooks because the call is made when an event occurs, for example, a sign up.
 - **Process claims**. If a user enters their first name in all lowercase or all uppercase letters, your REST API can format the name with only the first letter capitalized and return it to Azure AD B2C. However, when using a custom policy, [ClaimsTransformations](claimstransformations.md) is preferred over calling a RESTful API. 
 - **Dynamically enrich user data by further integrating with corporate line-of-business applications**. Your RESTful service can receive the user's email address, query the customer's database, and return the user's loyalty number to Azure AD B2C. Then return claims can be stored in the user's Azure AD account, evaluated in the next orchestration steps, or included in the access token.
 - **Run custom business logic**. You can send push notifications, update corporate databases, run a user migration process, manage permissions, audit databases, and perform any other workflows.
 
 ![Diagram of a RESTful service claims exchange](media/api-connectors-overview/restful-service-claims-exchange.png)
 
 > [!NOTE]
-> If there is slow or no response from the RESTful service to Azure AD B2C, the timeout is 30 seconds and the retry count is two times (meaning there are 3 tries in total). The timeout and retry count settings are not currently configurable.
+> If there is slow or no response from the RESTful service to Azure AD B2C, the timeout is 30 seconds and the retry count is two times (meaning there are 3 tries in total). Currently, you can't configure the timeout and retry count settings.
 
 ## Calling a RESTful service
 
@@ -149,7 +149,7 @@ The output claims should look like the following xml snippet:
 
 ### Handling null values 
 
-A null value in a database is used when the value in a column is unknown or missing.  Do not include JSON keys with a `null` value. In the following example, the email returns `null` value:
+A null value in a database is used when the value in a column is unknown or missing.  Don't include JSON keys with a `null` value. In the following example, the email returns `null` value:
 
 ```json
 {
@@ -231,7 +231,7 @@ In a RESTful technical profile, you may want to send the current session's langu
 
 ## Handling error messages
 
-Your REST API may need to return an error message, such as "The user was not found in the CRM system." If an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code). For more information, see the [RESTful technical profile](restful-technical-profile.md#returning-validation-error-message).
+Your REST API may need to return an error message, such as "The user wasn't found in the CRM system." If an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code). For more information, see the [RESTful technical profile](restful-technical-profile.md#returning-validation-error-message).
 
 This behavior can only be achieved by calling a REST API technical profile from a validation technical profile. Letting the user to correct the data on the page and run the validation again upon page submission.
 
@@ -272,3 +272,6 @@ See the following articles for examples of using a RESTful technical profile:
 - [Reference: RESTful technical profile](restful-technical-profile.md)
 
 ::: zone-end
+
+- Learn how to build resilience when [Interfacing with external processes](../active-directory/fundamentals/resilient-external-processes.md?bc=%2fazure%2factive-directory-b2c%2fbread%2ftoc.json&toc=%2fazure%2factive-directory-b2c%2fTOC.json)
+- Learn how to build [Resilience through developer best practices](../active-directory/fundamentals/resilience-b2c-developer-best-practices.md?bc=%2fazure%2factive-directory-b2c%2fbread%2ftoc.json&toc=%2fazure%2factive-directory-b2c%2fTOC.json).

articles/active-directory-b2c/configure-tokens.md

@@ -8,7 +8,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 10/15/2021
+ms.date: 12/16/2022
 ms.custom: project-no-code
 ms.author: kengaderdus
 ms.subservice: B2C
@@ -56,7 +56,7 @@ To configure your user flow token lifetime:
 1. Open the user flow that you previously created.
 1. Select **Properties**.
 1. Under **Token lifetime**, adjust the properties to fit the needs of your application.
-1. Click **Save**.
+1. Select **Save**.
 
 
 
@@ -106,7 +106,7 @@ The following values are set in the previous example:
 You can configure the token compatibility, including:
 
 - **Issuer (iss) claim** - The access and ID token issuer format.
-- **Subject (sub) claim** - The principal about which the token asserts information, such as the user of an application. This value is immutable and cannot be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource. By default, the subject claim is populated with the object ID of the user in the directory.
+- **Subject (sub) claim** - The principal about which the token asserts information, such as the user of an application. This value is immutable and can't be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource. By default, the subject claim is populated with the object ID of the user in the directory.
 - **Claim representing user flow** - This claim identifies the user flow that was executed. Possible values: `tfp` (default), or `acr`.
 
 ::: zone pivot="b2c-user-flow"
@@ -117,13 +117,13 @@ To configure your user flow compatibility settings:
 1. Open the user flow that you previously created.
 1. Select **Properties**.
 1. Under **Token compatibility settings**, adjust the properties to fit the needs of your application.
-1. Click **Save**.
+1. Select **Save**.
 
 ::: zone-end
 
 ::: zone pivot="b2c-custom-policy"
 
-To change the settings on your token compatibility, you set the [Token Issuer](jwt-issuer-technical-profile.md) technical profile metadata in the extension, or the relying party file of the policy you want to impact. The token issuer technical profile looks like following example:
+To change the settings on your token compatibility, you set the [Token Issuer](jwt-issuer-technical-profile.md) technical profile metadata in the extension, or the relying party file of the policy you want to update. The token issuer technical profile looks like following example:
 
 ```xml
 <ClaimsProviders>
@@ -186,7 +186,7 @@ The application claims are values that are returned to the application. Update y
 1. Open the user flow that you previously created.
 1. Select **Application claims**.
 1. Choose the claims and attributes that you want send back to your application.
-1. Click **Save**.
+1. Select **Save**.
 
 ::: zone-end
 
@@ -233,8 +233,9 @@ The OutputClaim element contains the following attributes:
 
 ## Authorization code lifetime
 
-When using the [OAuth 2.0 authorization code flow](authorization-code-flow.md), the app can use the authorization code to request an access token for a target resource. Authorization codes are short-lived that expire after about 10 minutes. The authorization code lifetime cannot be configured. Make sure your application redeems the authorization codes within 10 minutes. 
+When using the [OAuth 2.0 authorization code flow](authorization-code-flow.md), the app can use the authorization code to request an access token for a target resource. Authorization codes are short-lived that expire after about 10 minutes. The authorization code lifetime can't be configured. Make sure your application redeems the authorization codes within 10 minutes. 
 
 ## Next steps
 
-Learn more about how to [request access tokens](access-tokens.md).
+- Learn more about how to [request access tokens](access-tokens.md).
+- Learn how to build [Resilience through developer best practices](../active-directory/fundamentals/resilience-b2c-developer-best-practices.md?bc=%2fazure%2factive-directory-b2c%2fbread%2ftoc.json&toc=%2fazure%2factive-directory-b2c%2fTOC.json).