Merge pull request #11625 from gsacavdm/patch-3

articles/active-directory-b2c/active-directory-b2c-overview-custom.md

@@ -56,9 +56,9 @@ Built-in policies in Azure AD B2C follow the 3-file pattern depicted above, but
 
 Azure’s customer identity and access management (CIAM) service. The service includes:
 
-    1. A user directory in the form of a special-purpose Azure Active Directory accessible via Microsoft Graph and which holds user data for both local accounts and federated accounts 
-    2. Access to the **Identity Experience Engine** which orchestrates trust between users and entities and passes claims between them to complete an identity/access management task 
-    3. A security token service (STS) issuing id tokens, refresh tokens, and access tokens (and equivalent SAML assertions) and validating them to protect resources.
+1. A user directory in the form of a special-purpose Azure Active Directory accessible via Microsoft Graph and which holds user data for both local accounts and federated accounts 
+2. Access to the **Identity Experience Engine** which orchestrates trust between users and entities and passes claims between them to complete an identity/access management task 
+3. A security token service (STS) issuing id tokens, refresh tokens, and access tokens (and equivalent SAML assertions) and validating them to protect resources.
 
 Azure AD B2C interacts with identity providers, users, other systems, and with the local user directory in sequence to achieve an identity task (e.g. login a user, register a new user, reset a password). The underlying platform which establishes multi-party trust and executes these steps is called the Identity Experience Engine and a policy (also called an user journey or a Trust framework policy) explicitly defines the actors, the actions, the protocols, and the sequence of steps to complete.
 
@@ -105,4 +105,4 @@ A custom policy is represented as one or several XML-formatted files which refer
 
 When an application calls the RP Policy file, the Identity Experience Engine in B2C will add all the elements from BASE, then from EXTENSIONS, and lastly from the RP policy file to assemble the current policy in effect.  Elements of the same type and name in the RP file will override those in the EXTENSIONS, and EXTENSIONS overrides BASE.
 
-**Built-in policies** in Azure AD B2C follow the 3-file pattern depicted above, but the developer only sees the Relying Party (RP) file, while the portal makes changes in the background to the EXTenstions file.  All of Azure AD B2C shares a BASE policy file that is under the control of the Azure B2C team and is updated frequently.
+**Built-in policies** in Azure AD B2C follow the 3-file pattern depicted above, but the developer only sees the Relying Party (RP) file, while the portal makes changes in the background to the EXTenstions file.  All of Azure AD B2C shares a BASE policy file that is under the control of the Azure B2C team and is updated frequently.