Skip to main content
This Process consumes an authentication identifier (authN ID) and password to create a new User on the platform. This Process defines the initial onboarding flow for a new user who signs up with their email address and/or mobile number. Storefront Gateway uses the user’s supplied email address or mobile number as the basis for User ID creation. The email/mobile is registered as an unverified authentication identifier (or authN ID) that subsequently needs to be verified by the Activate User Process before the user can Authenticate into the service.

​
Process Flow

This section describes the Onboard with Email/Mobile Process from a high-level, “happy path” flow. Preconditions
  • The user is currently anonymous (i.e., they are not authenticated).
  • The User ID does not yet exist in Storefront Gateway (i.e., the Storefront Gateway User entity does not yet exist in the cloud data store).
Basic Flow
  1. The user navigates to your application’s sign-in page, and submits their email and/or mobile number, plus any other information required by the application. Input fields are:
    • Email Address – The user’s email. Required if a mobile number is not provided.
    • Mobile Number – The user’s mobile number. Required if an email address is not provided.
    • Password – The user’s desired password. Required.
    • Additional Fields – Optional user input fields that the Process accepts: First Name, Last Name, Display Name (can be used in place of first and last), and Language.
  2. Storefront Gateway creates the User entity. The email/mobile is stored an authentication identifier (authN ID) and attribute on the User entity. Both the User entity and authN ID are created with an activating status, pending verification.
  3. Storefront Gateway sends a verification message to the email address or mobile number supplied by the user. The following conditions apply:
    • A verification message contains an action token Storefront Gateway Action Token, and the token can be delivered to the user as either a clickable redirect URL, a short custom One-time Passcode (OTP), or both. The type of token in the message depends on your organization’s notification settings.
    • If the user provided both an email address and mobile number, then separate notification message are sent to both contact channels, each with their own respective tokens.
    • Any Storefront Gateway Process that results in an action token being sent to an external channel will also return a corresponding to the client application. The application should retain this information for onboarding flows wherein the user needs to provide their OTP to the UI, or for a resend verification option.
  4. Storefront Gateway sends a corresponding pkat
Storefront Gateway Action Token to your client application. The client application retains this information for onboarding flows where the user needs to enter their OTP directly to the UI. The PKAT can also be used in cases where the client wants to display a resend verification message option on the post-onboarding page. Post-conditions
  • A new User entity exists in Storefront Gateway with an unverified email and/or mobile. The user must verify the authN ID before they can authenticate into the service with it.
  • The user receives a verification message through email or SMS.
Possible or Common Errors
  • The provided email already or mobile number is already registered to an existing Storefront Gateway User.
  • The provided password does not match complexity settings.
  • The email or mobile does not pass validation rules.
  • The client submitted a request with a missing expected input parameter (e.g., no email or mobile provided)

​
App Settings

Certain aspects of the Process’ behavior are controlled by configurable settings that you can manage from the Admin console.

​
User Journey Diagram

This diagram illustrates the standard user journey using the Onboarding with Email or Mobile Process, and some of the paths the Process can take based on settings and/or user input. This diagram also incorporates a token resend option (with the [PUT /session/token](c_putSessionToken) API) and the Activate User Processes, to give a better idea of the true end-to-end onboarding journey.

​
Use Cases

The following use cases provide guided API walk-throughs of this Process for client developers: Parent topic:Identity Management Processes