Using the form builder

In journey steps like Login Form and Get Information from Client, schemas define the data expected from the client and also affect the UI rendering if using Mosaic's auto-generated client-side forms. You can customize the default schema by adjusting fields, their order, or preset values in the form builder. This allows for precise control over the data structure and client-side rendering.

Manage schema in form builder

In the form builder, you can manage default schema:

  • Add new fields by selecting + Add field and configuring its settings.
  • Reorder fields by dragging and dropping the fields.
  • Delete fields you don't need
  • Copy schema in the JSON format to share with the development team

Customizable settings for each field include:

Field Description
Field name A field indentifier.
Label An optional field title used for client-side rendering. Can include expressions.
Default value Prefills the field value on the client side. Can include expressions.
Data type Defines the field data type, which can be string, number, or boolean. When rendered on the client side, boolean appears as a checkbox and number as a numeric input box. For string, it either renders as a plain text input or according to the format field described below.
Format Guides the client side on how to render string fields. Options include text, password, email, phone, date, date & time, or passkey.
- password, email, phone, date, date & time determine the appropriate input widget to display based on the specified format.
- passkey affects the Login Form step, enabling automatic passkey activation from text boxes.
For more, see the examples below.
Mandatory When set to true, the field will be considered mandatory input on the client side. Can include expressions, such expressions will be evaluated for being true or false, e.g., user.userEmail != null.
Read-only When set to true, the field will be displayed as read-only on the client side. Can include expressions, such expressions will be evaluated for being true or false, e.g., user.userEmail != null.

Examples

Below are examples of how to create various forms in journey flows. These examples illustrate different configurations for collecting user input, such as email, phone numbers, passwords, and more, in a structured and customizable way.

Collect email

This example displays a simple form that only asks for the user's email. It could be used as the first step to collect the user identifier before proceeding to a Sign-in or Sign-up flow.

The data type is set to string, indicating the type of value received in the journey. Additionally, setting the format to email ensures the UI input validates the email on the client side.

The client will present a form for retrieving this information and return response to the journey. For example:

Copy
Copied
window.tsPlatform.ido.submitClientResponse(
    ClientResponseOptionType.ClientInput,
    {userEmail: "someone@email.com"}
);

Collect email with a "Remember me" checkbox

Building on the previous example, this example includes a "Remember me" checkbox in addition to the email input. The "Remember me" field data type is boolean.

The client will present a form for retrieving this information and return response to the journey. For example:

Copy
Copied
window.tsPlatform.ido.submitClientResponse(
    ClientResponseOptionType.ClientInput,
    {userEmail: "someone@email.com", rememberMe: true}
);

Collect email and password

This example represents a typical login form where the username is an email, and authentication requires a password. Like the email field, the password field has a string data type, but setting the format to password instructs the client to render a password input box. Both fields are mandatory and will be rendered in the order they are appear in the form builder.

The client will present a form for retrieving this information and return response to the journey. For example:

Copy
Copied
window.tsPlatform.ido.submitClientResponse(
    ClientResponseOptionType.ClientInput,
    {userEmail: "someone@email.com", userPassword: "MyPass123"}
);

Collect email, phone, and password

This example represents a simple onboarding form where we collect an email, phone number, and password (entered twice). Unlike other fields, the "Phone number" isn't set as mandatory, meaning UI will not enforce the user to fill it.

The client will present a form for retrieving this information and return response to the journey. For example:

Copy
Copied
window.tsPlatform.ido.submitClientResponse(
    ClientResponseOptionType.ClientInput,
    {
      userEmail: "someone@email.com",
      userPhone: "12127001234",
      userPassword: "MyPass123",
      retypePassword: "MyPass123"
    }
);

Update user's details

This example represents a form for updating user's personal information. The client side will check if the email address is available for the user (userEmail != null), the client side will prefill it for the user and make this field read-only.

The client will present a form for retrieving this information, prefill the user email (if exists) and return response to the journey. For example:

Copy
Copied
window.tsPlatform.ido.submitClientResponse(
    ClientResponseOptionType.ClientInput,
    {
      userEmail: "someone@email.com",
      userPhone: "12127001234",
      userPassword: "MyPass123",
      userAddress: "PO Box 1234 Anytown, CA 12345"
    }
);