PR review team comments

kengaderdus · kengaderdus · commit 7503aed04e80 · 2023-02-01T00:21:53.000+03:00
diff --git a/articles/active-directory-b2c/custom-policies-series-collect-user-input.md b/articles/active-directory-b2c/custom-policies-series-collect-user-input.md
@@ -45,7 +45,7 @@ In this article, you'll learn how to write a custom policy that collects user in
 
 [!INCLUDE [active-directory-b2c-app-integration-call-api](../../includes/active-directory-b2c-common-note-custom-policy-how-to-series.md)]
 
-## Step 1 - Declare Claims
+## Step 1 - Declare claims
 
 Declare additional claims alongside *objectId* and *message*: 
 
@@ -82,7 +82,7 @@ Declare additional claims alongside *objectId* and *message*:
 - **DisplayName** specifies the label for the UI control that appears on the user interface if you want to collect the value of the claim from the user.
 
 
-## Step 2 - Define Claims Transformations 
+## Step 2 - Define claims transformations 
 
 A [ClaimsTransformation](claimstransformations.md) contains a function that you use to convert a given claim into another one. For instance, you can change a string claim from lower case to upper case. Learn more about [Claims transformations supported by Azure AD B2C](claimstransformations.md#claims-transformations-reference). 
 
@@ -138,7 +138,7 @@ A [ClaimsTransformation](claimstransformations.md) contains a function that you
     
     -  *CreateMessageTransformation* concatenates *Hello* and *displayName* to form *message*. 
 
-## Step 3 - Configure Content Definitions
+## Step 3 - Configure content definitions
 
 [ContentDefinitions](contentdefinitions.md) allow you to specify URL to HTML templates that control the layout of the web pages you show to your users. You can specify specific user interfaces for each step, such as sign-in or sign-up, password reset, or error pages.
 
@@ -154,15 +154,15 @@ To add content definition, add the following code in `BuildingBlocks` section of
     </ContentDefinitions>
 ```   
 
-## Step 4 - Configure Technical Profiles  
+## Step 4 - Configure technical profiles  
 
 In a custom policy, a [TechnicalProfile](technicalprofiles.md) is the element that implements functionality. Now that you've defined Claims and Claims Transformations, you need Technical Profiles to execute your definitions. A technical profile is declared inside the `ClaimsProvider` elements.
 
 Azure AD B2C provides a set of technical profiles. Each technical profile performs a specific role. For instance, you use a [REST technical profile](restful-technical-profile.md) to make an HTTP call to a service endpoint. You can use a claims transformation technical profile to execute the operation you define in a Claims Transformation. Learn more about the [types of technical profiles](technicalprofiles.md) that Azure AD B2C custom policies provide.
 
 ### Set values for your claims 
  
-To set values for *objectId*, *displayName* and *message* claims, you configure a technical profile that executes the *GenerateRandomObjectIdTransformation*, *CreateDisplayNameTransformation*, and *CreateMessageTransformation* claims transformations. The claims transformation are executed by the order defined in the OutputClaimsTransformations element. For example, it first creates the display name, then the message. 
+To set values for *objectId*, *displayName* and *message* claims, you configure a technical profile that executes the *GenerateRandomObjectIdTransformation*, *CreateDisplayNameTransformation*, and *CreateMessageTransformation* claims transformations. The claims transformations are executed by the order defined in the `OutputClaimsTransformations` element. For example, it first creates the display name, then the message. 
 
 1. Add the following `ClaimsProvider` as a child of the `ClaimsProviders` section. 
     
@@ -233,7 +233,7 @@ You generate the *displayName* claim from *givenName* and *surname*, so you need
 
     Notice the two display claims for the *givenName* and *surname* claims. Both of the claims are marked as required, so the user must enter the values before they submit the form displayed to them. The claims are displayed on the screen in the order defined in the *DisplayClaims* element such as, the **Given Name** and then the **Surname**. 
 
-## Step 5 - Define User Journeys
+## Step 5 - Define user journeys
 
 You use user journeys to define order in which the technical profiles are called. You use the `OrchestrationSteps` element to specify the steps in a user journey. 
 
@@ -257,7 +257,7 @@ Replace the existing contents of the `HelloWorldJourney` User Journey with the f
 
 According to the orchestration steps, we collect user inputs, set values for *objectId*, *displayName* and *message* claims, and finally send the Jwt token. 
 
-## Step 6 - Update Relying Party 
+## Step 6 - Update relying party 
 
 Replace the contents of the `OutputClaims` element of the `RelyingParty` section with the following code: 
 
diff --git a/articles/active-directory-b2c/custom-policies-series-hello-world.md b/articles/active-directory-b2c/custom-policies-series-hello-world.md
@@ -81,7 +81,7 @@ If you haven't already done so, create the following encryption keys. To automat
     ```
     Replace `yourtenant` with the subdomain part of your tenant name, such as `contoso`. Learn how to [Get your tenant name](tenant-management-read-tenant-name.md#get-your-tenant-name). 
 
-    The XML elements define the top-level `TrustFrameworkPolicy` element of a policy file with its policy ID and tenant name. The TrustFrameworkPolicy element contains other XML elements that you will use in this series.
+    The XML elements define the top-level `TrustFrameworkPolicy` element of a policy file with its policy ID and tenant name. The TrustFrameworkPolicy element contains other XML elements that you'll use in this series.
 
 1. To declare a claim, add the following code in `BuildingBlocks` section of the `ContosoCustomPolicy.XML` file: 
 
@@ -147,7 +147,7 @@ If you haven't already done so, create the following encryption keys. To automat
       </UserJourney>
     ```
     
-    We've added a [UserJourney](userjourneys.md). The user journey specifies the business logic the end user goes through as Azure AD B2C processes a request. This user journey has only one step that issues a JTW token with the claims the you will define in the next step.
+    We've added a [UserJourney](userjourneys.md). The user journey specifies the business logic the end user goes through as Azure AD B2C processes a request. This user journey has only one step that issues a JTW token with the claims that you'll define in the next step.
 
 1.  In the `RelyingParty` section of the `ContosoCustomPolicy.XML` file, add the following code:
 
diff --git a/articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in-federation.md b/articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in-federation.md
@@ -50,16 +50,16 @@ Use the steps outlined in [Create the Facebook key](identity-provider-facebook.m
 
 To configure sign in with Facebook, you need to perform the following steps:
 
-- Declare additional claims
-- Define additional Claims transformations to help with claims manipulations such as creating *AlternativeSecurityId*.
+- Declare more claims
+- Define more claims transformations to help with claims manipulations such as creating *AlternativeSecurityId*.
 - Configure Facebook claims provider
-- Configure Azure AD Technical Profiles to read and write the social account from and to the Azure AD database.
-- Configure a SelfAsserted technical profile (for accepting additional input from user or updating user details) and its content definition. 
+- Configure Azure AD technical profiles to read and write the social account from and to the Azure AD database.
+- Configure a self-asserted technical profile (for accepting additional input from user or updating user details) and its content definition. 
 
 
-### Step 3.1 - Declare additional claims 
+### Step 3.1 - Declare more claims 
 
-In the `ContosoCustomPolicy.XML` file, locate the *ClaimsSchema* section, and then declare additional claims by using the following code:
+In the `ContosoCustomPolicy.XML` file, locate the *ClaimsSchema* section, and then declare more claims by using the following code:
 
 ```xml
     <!--<ClaimsSchema>-->
@@ -152,7 +152,7 @@ In the `ContosoCustomPolicy.XML` file, locate the *ClaimsTransformations* elemen
     <!--</ClaimsTransformations>-->
  ```
 
-We've defined three Claims Transformations, which we use to generate values for *alternativeSecurityId* and *userPrincipalName* claims. These ClaimsTransformations are invoked in the OAuth2 Technical Profile in [step 3.3](#step-33---configure-facebook-claims-provider).   
+We've defined three Claims Transformations, which we use to generate values for *alternativeSecurityId* and *userPrincipalName* claims. These ClaimsTransformations are invoked in the OAuth2 technical profile in [step 3.3](#step-33---configure-facebook-claims-provider).   
 
 ### Step 3.3 - Configure Facebook claims provider
 
@@ -259,7 +259,7 @@ Just like in sign-in with a local account, you need to configure the [Azure AD T
 
 1. Replace *B2C_1A_TokenSigningKeyContainer* with the token signing key you created in [Configure the signing](custom-policies-series-hello-world.md#step-1---configure-the-signing-and-encryption-keys).  
  
-1. In the `ContosoCustomPolicy.XML` file add another Azure AD technical profile after the *AAD-UserWriteUsingAlternativeSecurityId* Technical Profile by using the following code:   
+1. In the `ContosoCustomPolicy.XML` file, add another Azure AD technical profile after the *AAD-UserWriteUsingAlternativeSecurityId* Technical Profile by using the following code:   
 
      ```xml
         <TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
@@ -502,7 +502,7 @@ Notice the identity provider, `"idp": "facebook.com"`, has been included in the
 
 ## A combined local and social sign-in
 
-In this article, our user journey orchestration steps only references technical profiles that enable a user to sign in by using a social account. We can modify the orchestration steps to enable a user to sign in by using either a local account or  a social account. To do so, the first orchestration step's `ClaimsProviderSelections` element lists the sign in options available to the user. 
+In this article, our user journey orchestration steps only reference technical profiles that enable a user to sign in by using a social account. We can modify the orchestration steps to enable a user to sign in by using either a local account or  a social account. To do so, the first orchestration step's `ClaimsProviderSelections` element lists the sign-in options available to the user. 
 
 Use the following steps to add a combined local and social account: 
 
@@ -525,7 +525,7 @@ Use the following steps to add a combined local and social account:
         <!--</UserJourneys>-->
     ```
 
-1. In the user journey you just created, *LocalAndSocialSignInAndSignUp*, add orchestration steps by using the following code:
+1. In the user journey you've created, *LocalAndSocialSignInAndSignUp*, add orchestration steps by using the following code:
  
     ```xml
         <!--<UserJourneys>
@@ -680,7 +680,7 @@ Use the following steps to add a combined local and social account:
 
 1. Use the procedure in [step 6](#step-6---upload-policy) and [step 7](#step-7---test-policy) to upload and run your policy. After you run the policy, you'll see a screen similar to the following screenshot.
 
-    :::image type="content" source="media/custom-policies-series-sign-up-or-sign-in-federation/screenshot-combined-local-and-social-sign-up-or-sign-in.png" alt-text="A screenshot combined local and social sign up or sign in interface.":::
+    :::image type="content" source="media/custom-policies-series-sign-up-or-sign-in-federation/screenshot-combined-local-and-social-sign-up-or-sign-in.png" alt-text="A screenshot of combined local and social sign-up or sign-in interface.":::
 
     You can observe that a user can sign up or sign in by using either a local account or a social account. 
 
diff --git a/articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in.md b/articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in.md
@@ -45,15 +45,15 @@ Azure AD B2C custom policy provides a OpenID Connect technical profile, which yo
 
 ## Step 1 - Configure OpenID Connect technical profile
 
-To configure an OpenID Connect Technical Profile you need to perform three steps: 
+To configure an OpenID Connect technical profile, you need to perform three steps: 
 
-- Declare additional claims. 
+- Declare more claims. 
 - Register apps in your Azure portal.
 - Finally, configure OpenID Connect Technical Profile itself
 
-### Step 1.1 - Declare additional claims
+### Step 1.1 - Declare more claims
 
-In the `ContosoCustomPolicy.XML` file, locate the *ClaimsSchema* section, and then add additional claims by using the following code:
+In the `ContosoCustomPolicy.XML` file, locate the *ClaimsSchema* section, and then add more claims by using the following code:
 
 ```xml
     <!--<ClaimsSchema>-->
@@ -98,9 +98,9 @@ Azure AD B2C requires you to register two applications that it uses to sign up a
 
 If you haven't already done so, register the following applications. To automate the walk-through below, visit the [IEF Setup App](https://aka.ms/iefsetup) and follow the instructions:
 
-1. Follow the steps in [Register the IdentityExperienceFramework application](tutorial-create-user-flows.md?pivots=b2c-custom-policy#register-the-identityexperienceframework-application) to register the Identity Experience Framework application. Copy the **Application (client) ID**, *appID*, for the Identity Experience Framework application registration for use on the next step.  
+1. Use the steps in [Register the IdentityExperienceFramework application](tutorial-create-user-flows.md?pivots=b2c-custom-policy#register-the-identityexperienceframework-application) to register the Identity Experience Framework application. Copy the **Application (client) ID**, *appID*, for the Identity Experience Framework application registration for use on the next step.  
 
-1. For low the steps in [Register the ProxyIdentityExperienceFramework application](tutorial-create-user-flows.md?pivots=b2c-custom-policy#register-the-proxyidentityexperienceframework-application) to register Proxy Identity Experience Framework application. Copy the **Application (client) ID**, *proxyAppID*, for the Proxy Identity Experience Framework application registration for use on the next step.
+1. Use the steps in [Register the ProxyIdentityExperienceFramework application](tutorial-create-user-flows.md?pivots=b2c-custom-policy#register-the-proxyidentityexperienceframework-application) to register Proxy Identity Experience Framework application. Copy the **Application (client) ID**, *proxyAppID*, for the Proxy Identity Experience Framework application registration for use on the next step.
 
 ### Step 1.3 - Configure OpenID Connect technical profile
 
@@ -191,7 +191,7 @@ In the `ContosoCustomPolicy.XML` file, locate the `SignInUser` technical profile
     </TechnicalProfile>
 ```
 
-We've added a SelfAsserted Technical Profile, *UserSignInCollector*, which displays the sign-in form to the user. We've configured the technical profile to collect the user’s email address as their sign-in name as indicated in the `setting.operatingMode` metadata. The sign in form includes a sign-up link, which leads the user to a sign-up form as indicated by the `SignUpTarget` metadata. You'll see how we set up the *SignUpWithLogonEmailExchange* `ClaimsExchange` in the orchestration steps.
+We've added a SelfAsserted Technical Profile, *UserSignInCollector*, which displays the sign-in form to the user. We've configured the technical profile to collect the user’s email address as their sign-in name as indicated in the `setting.operatingMode` metadata. The sign-in form includes a sign-up link, which leads the user to a sign-up form as indicated by the `SignUpTarget` metadata. You'll see how we set up the *SignUpWithLogonEmailExchange* `ClaimsExchange` in the orchestration steps.
 
 Also, we've added the *SignInUser* OpenID Connect Technical Profile as a *ValidationTechnicalProfile*. So, the *SignInUser* technical profile executes when the user selects the **Sign in** button (see screenshot in [step 5](#step-5---test-policy)).    
 
diff --git a/articles/active-directory-b2c/custom-policies-series-store-user.md b/articles/active-directory-b2c/custom-policies-series-store-user.md
diff --git a/articles/active-directory-b2c/tutorial-create-tenant.md b/articles/active-directory-b2c/tutorial-create-tenant.md
