Create User
Add a user to the Mosaic identity management platform.
Description
This step is used to create a user in the Mosaic identity management platform. 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 a 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 can direct the user to an alternative flow, such as 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 3).
Configuration
| Field | Description |
|---|---|
| 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. |
| Secondary Emails | Expressions that yield a list of secondary emails of the user (e.g., [clientData.secondary_email1, clientData.secondary_email2], where clientData is an input collected from the user.) |
| Secondary Phone Numbers | Expressions that yield a list of secondary phone numbers of the user in E.164 format. (e.g., [clientData.secondary_phone1, clientData.secondary_phone2], where clientData is an input collected from the user.) |
| Birthday | Date-time string in ISO-8601 format for the user's birthday. For example, an expression like @time.nowISO("EST") gets the current date and time in ISO 8601 format for the Eastern Standard Time zone. |
| Custom Data | Additional custom data for the user in JSON object format. |
| Actor ID | Expression that yields the ID of the primary user that has permissions to act on behalf of this user. |
| Permissions | List of strings of permissions granted to the primary user on behalf of the dependent. |
| 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. |
| If User Already Exists | Behavior if the user already exists: by default, the journey proceeds to a user already exists branch in the control flow, or it aborts the journey. |
Example
Here are some examples of using this step:
- Example 1: Basic User Creation
- Example 2: Handling Existing User with Alternative Flow
- Example 3: Handling User Creation with Limited Attempts
Example 1: Basic User Creation
Suppose a user needs to be created with the following details: email, phone, username, and birthday. 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.
Next, the user record is created to store the collected data. The username is used as the primary identifier, so it is set in the External User ID field.
Before concluding the journey, the email address will be validated by performing Email OTP authentication.
Example 2: Handling Existing User with Alternative Flow
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 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 create_user_output, allowing the journey to proceed to register mobile biometrics. 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 Display Information step, showing a message to attempt sign-in or recover the account. If the user chooses to recover the account, they can proceed through an alternative recovery flow. If further attempts to use existing identifiers are made, this secondary flow can eventually lead to a Reject Access step.
Example 3: 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.
