Create User
Adds a user to the Mosaic identity management platform.
Description
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 either an email, a phone number, a username, or a combination of these to associate the user record with an external user identifier. For example, it can be utilized in user sign-up journeys after collecting user information via the Get Information From Client 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).
Configuration
| 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. |
| External User ID * | Mandatory expression that yields the main user identifier used in orchestration. It is unique at the tenant level. |
| 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, 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, 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, or any combination of these. |
| Application custom data | Expression that yields a JSON object containing the user's data specific to the current application. |
| Tenant custom data | Expression that yields a JSON object containing the user's data shared by all apps in your tenant. |
| First name | Expression that yields a user's first name (e.g., clientData.firstName, where clientData is an input collected from the user.) |
| Middle name | Expression that yields a user's middle name (e.g., clientData.middleName, where clientData is an input collected from the user.) |
| Last name | Expression that yields a user's last name (e.g., clientData.lastName, where clientData is an input collected from the user.) |
| Additional user data | Includes expressions that yield various user profile details, such as title, country, city, language, birthday, secondary emails and phone numbers. |
| 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. |
Example
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
Example 1: User creation and handling existing user
Suppose a banking application requires that the username matches the actual account number of a bank account. If a user tries to sign up with an existing account number, 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 Get Information From Client 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.username) will be set as the External User ID in the Create User step to create the user record.
Next, the user record is created to store the collected data. If the username 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.
Example 2: Handling user creation with limited attempts
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 user's username is collected using the Get Information From Client, 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 External User ID 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.
