Adds a user to the Mosaic identity management platform
This step is used to create a user in Mosaic. During the user record creation, it allows you to register extensive user information through various user-related fields. However, in terms of user information, it only mandates specifying an identifier–either an email, a phone number, a username, external user ID, or any custom identifier (if exists), or a combination of these. For example, it can be utilized in user sign-up journeys after collecting user information via the Collect information step to effectively record the collected information.
The step is successful if the user does not already exist, that is, when the user identifiers entered do not match any existing user records. In this case, it provides output variables for further use in the journey.
For handling cases where the journey fails due to generic errors, this step includes the Failure Behavior branch, that either aborts the journey or proceeds to a failure branch of the control flow.
For handling cases where the user identifiers match an already existing user, this step includes the UserAlreadyExistsBranch. If the user already exists, this branch will direct the user to an alternative flow, such as a login flow or a recovery flow to retrieve their credentials. For example, if a user tries to sign up with an existing username, the UserAlreadyExistsBranch can introduce a Display information step that prompts the user to recover their account instead, and connects to the relevant nodes.
Consider placing the Create User step inside the While loop step for scenarios where you allow a certain number of creation attempts before deferring to the failure branch or alternative branch (see example 2).
| Field | Description |
|---|---|
| Set as authenticated | Allows to proceed based on the initial user creation as if the user has completed authentication. See Auth state for more details. |
| Email * | Expression that yields the user's main email address. It is unique at the tenant level. Note: it is mandatory to specify at least one of the following: an email, a phone number, a username, a custom identifier, or any combination of these. |
| Phone * | Expression that yields the user's main phone number in E.164 format. It is unique at the tenant level. Note: it is mandatory to specify at least one of the following: an email, a phone number, a username, a custom identifier, or any combination of these. |
| Username * | Expression that yields the user's username, commonly used in username and password authentication. It is unique at the app level. Note: it is mandatory to specify at least one of the following: an email, a phone number, a username, a custom identifier, or any combination of these. |
| External user ID * | Expression that yields the main user identifier used in orchestration. It is unique at the tenant level. Note: it is mandatory to specify at least one of the following: an email, a phone number, a username, a custom identifier, or any combination of these. |
| (Custom) * | (Only B2C Identity) Expression that yields the value for the custom identifier defined in the user schema. It is unique at the tenant level. Note: it is mandatory to specify at least one of the following: an email, a phone number, a username, a custom identifier, or any combination of these. For more about custom identifiers, see Customize user schema. |
| Built-in attributes | Includes expressions that yield various user profile details, such as first and last name, title, country, city, language, birthday, secondary emails and phone numbers. |
| Custom attributes | (Only B2C Identity) Includes expressions that yield various user profile details defined as custom attributes in the user schema for your tenant. The list changes dynamically based on the user schema. For more about custom attributes, see Customize user schema. |
| Error output variable | Name of the variable that stores any errors returned by the step. |
| Output variable | Name of the variable that includes the result object from the Create User API. |
| Failure behavior | Behavior in case of failure: by default, the journey proceeds to a failure branch in the control flow, or it aborts the journey. |
Here are some examples of using this step:
- Example 1: Basic user creation and handling existing user
- Example 2: Handling user creation with limited attempts
Suppose a gym application requires a user to sign up and log in with the actual member ID found on the gym card. If a user tries to sign up with an existing member ID, the app directs the user to an alternative flow, such as a login flow, or an account recovery flow.
First, the user's details are collected by adding the Collect information step to the journey. The step ID for this form is set to user_data_form, the output variable is named clientData, and the schema contains input field descriptions for each of the details to be collected. The output variable data (clientData.memberID) will be set as the MemberID in the Create User step to create the user record. The MemberID is a custom identifier defined for B2C users in the tenant.
Next, the user record is created to store the collected data. If the member ID entered does not exist, the Success branch in the Create User step updates the create_user_output, allowing the journey to proceed to further steps, such as registering mobile biometrics for a new user. If there is a failure in the journey due to generic errors, this step proceeds to the Failure Behavior branch, which aborts the journey. If the user already exists, the UserAlreadyExistsBranch directs the user to a Login form step to attempt sign-in or recover the account.
Suppose a membership program allows users to choose their own user identifier. In this scenario, we need to ensure that the chosen identifier is unique. To provide the user with the opportunity to find an available identifier, we limit the number of attempts the user can make by including the sign-up journey within a While Loop.
First, the desired username is collected using the Collect information, where the step ID is user_data_form and the output variable is clientData. The output variable data (clientData.username) will be set as the username in the Create User step to create the user record.
If the username entered does not exist, the Success branch updates the UserIsCreated variable to true, allowing the journey to proceed and eventually complete successfully.
If the user already exists, the UserAlreadyExistsBranch does not update the UserIsCreated variable and increments the attempt_count variable. The journey loops back to the user details form, prompting the user to choose a different identifier. If the attempt_count exceeds a specified limit (e.g., 5 attempts), the journey proceeds to a Reject Access step, completing the journey with a rejection due to too many failed attempts.
