Merge pull request #91476 from bolt-io/patch-11

Updates from ATCP B2C Pages review

Author: Court72

articles/active-directory-b2c/userjourneys.md

@@ -21,7 +21,16 @@ User journeys specify explicit paths through which a policy allows a relying par
 
 These user journeys can be considered as templates available to satisfy the core need of the various relying parties of the community of interest. User journeys facilitate the definition of the relying party part of a policy. A policy can define multiple user journeys. Each user journey is a sequence of orchestration steps.
 
-To define the user journeys supported by the policy, a **UserJourneys** element is added under the top-level element of the policy file.
+To define the user journeys supported by the policy, a `UserJourneys` element is added under the top-level `TrustFrameworkPolicy` element of the policy file.
+
+```xml
+<TrustFrameworkPolicy  ...>
+  ...
+  <UserJourneys>
+    ...
+  </UserJourneys>
+</TrustFrameworkPolicy>
+```
 
 The **UserJourneys** element contains the following element:
 
@@ -51,13 +60,13 @@ The **AuthorizationTechnicalProfiles** element contains the following element:
 
 | Element | Occurrences | Description |
 | ------- | ----------- | ----------- |
-| AuthorizationTechnicalProfile | 0:1 | List of authorization technical profiles. | 
+| AuthorizationTechnicalProfile | 0:1 | The technical profile reference used to authorize the user. | 
 
 The **AuthorizationTechnicalProfile** element contains the following attribute:
 
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
-| TechnicalProfileReferenceId | Yes | The identifier of the technical profile that is to be executed. |
+| ReferenceId | Yes | The identifier of the technical profile that is to be executed. |
 
 The following example shows a user journey element with authorization technical profiles:
 
@@ -81,6 +90,13 @@ Orchestration steps can be conditionally executed based on preconditions defined
 
 To specify the ordered list of orchestration steps, an **OrchestrationSteps** element is added as part of the policy. This element is required.
 
+```xml
+<UserJourney Id="SignUpOrSignIn">
+  <OrchestrationSteps>
+    <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
+      ...
+```
+
 The **OrchestrationSteps** element contains the following element:
 
 | Element | Occurrences | Description |
@@ -92,7 +108,7 @@ The **OrchestrationStep** element contains the following attributes:
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
 | `Order` | Yes | The order of the orchestration steps. |
-| `Type` | Yes | The type of the orchestration step. Possible values: <ul><li>**ClaimsProviderSelection** - Indicates that the orchestration step presents various claims providers to the user to select one.</li><li>**CombinedSignInAndSignUp** - Indicates that the orchestration step presents a combined social provider sign-in and local account sign-up page.</li><li>**ClaimsExchange** - Indicates that the orchestration step exchanges claims with a claims provider.</li><li>**GetClaims** - Specifies that the orchestration step should process claim data sent to Azure AD B2C from the relying party via its `InputClaims` configuration.</li><li>**InvokeSubJourney** - Indicates that the orchestration step exchanges claims with a [sub journey](subjourneys.md) (in public preview).</li><li>**SendClaims** - Indicates that the orchestration step sends the claims to the relying party with a token issued by a claims issuer.</li></ul> |
+| `Type` | Yes | The type of the orchestration step. Possible values: <ul><li>**ClaimsProviderSelection** - Indicates that the orchestration step presents various claims providers to the user to select one.</li><li>**CombinedSignInAndSignUp** - Indicates that the orchestration step presents a combined social provider sign-in and local account sign-up page.</li><li>**ClaimsExchange** - Indicates that the orchestration step exchanges claims with a claims provider.</li><li>**GetClaims** - Specifies that the orchestration step should process claim data sent to Azure AD B2C from the relying party via its `InputClaims` configuration.</li><li>**InvokeSubJourney** - Indicates that the orchestration step exchanges claims with a [sub journey](subjourneys.md).</li><li>**SendClaims** - Indicates that the orchestration step sends the claims to the relying party with a token issued by a claims issuer.</li></ul> |
 | ContentDefinitionReferenceId | No | The identifier of the [content definition](contentdefinitions.md) associated with this orchestration step. Usually the content definition reference identifier is defined in the self-asserted technical profile. But, there are some cases when Azure AD B2C needs to display something without a technical profile. There are two examples - if the type of the orchestration step is one of following: `ClaimsProviderSelection` or  `CombinedSignInAndSignUp`, Azure AD B2C needs to display the identity provider selection without having a technical profile. |
 | CpimIssuerTechnicalProfileReferenceId | No | The type of the orchestration step is `SendClaims`. This property defines the technical profile identifier of the claims provider that issues the token for the relying party.  If absent, no relying party token is created. |
 
@@ -124,7 +140,7 @@ The **Precondition** element contains the following attributes:
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
 | `Type` | Yes | The type of check or query to perform for this precondition. The value can be **ClaimsExist**, which specifies that the actions should be performed if the specified claims exist in the user's current claim set, or **ClaimEquals**, which specifies that the actions should be performed if the specified claim exists and its value is equal to the specified value. |
-| `ExecuteActionsIf` | Yes | Decides how the precondition is considered satisfied. Possible values: `true` (default), or `false`. If the value is set to `true`, it's considered satisfied when the claim matches the precondition.  If the value is set to `false`, it's considered satisfied when the claim doesn't match the precondition.  |
+| `ExecuteActionsIf` | Yes | Decides how the precondition is considered satisfied. Possible values: `true`, or `false`. If the value is set to `true`, it's considered satisfied when the claim matches the precondition.  If the value is set to `false`, it's considered satisfied when the claim doesn't match the precondition.  |
 
 The **Precondition** elements contains the following elements: