Gigya Job Openings


Skip to end of metadata
Go to start of metadata


SAP Customer Data Cloud provides registration, login and other flows out of the box, which cover the wide majority of scenarios encountered when consumers log in to your site. These user-facing flows are displayed as sets of successive screens, known as Screen-Sets.

You can customize these flows on two levels:

  • Change the appearance of the screens, add or remove fields, mark fields as mandatory and more. You customize the screens of a Screen-Set with the UI Builder, or by using Markup Extensions.
  • Change the flows and add new screens by manually editing the HTML and CSS code provided in the default screen-sets. 

By default, all Screen-Sets are responsive, and are automatically resized in accordance with the device on which they open. For more information, see UI Builder: Responsive Design.

Following is an outline of the major flows provided by SAP Customer Data Cloud:

In many cases, these flows are interconnected and one flow may be triggered from within another.

We invite you to play with these flows, using our working example.


Watch an Instructional Video

To watch a video about this subject, you can visit our Enablement portal with your approved SAP customer or partner ID (S user). Please visit the About page to find out how to get an S user.


Generally, people with disabilities may experience difficulty when using web pages and apps. Certain global standards may be applied to ensure that websites and apps are accessible. For example, a blind or partially blind person should be able to consume the important information on the page and to use it, aided by assistive technologies, such as a screen reader. The definitive guidelines for web accessibility are the Web Content Accessibility Guidelines (WCAG), created by the World Wide Web Consortium (W3C). This standard outlines 3 levels of accessibility, from lowest to highest: A, AA and AAA. According to W3C,  "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content" (source). 

All of the SAP Customer Data Cloud's default screens and Screen-Sets support WCAG compliance level AA, including:  

  • Labels and ARIA-labels for screen reader support
  • Correct indication to screen readers of mandatory fields, warning messages etc.
  • Full keyboard control (tabbing, entering information, exiting screens)
  • The default behavior of SAP Customer Data Cloud screens ensures that they integrate smoothly with your website flows. However, they are only one component of your website. It is still the site owner's responsibility to ensure that the entire page or site conforms with WCAG standards and that disabled users can use the site, including completing the flows in full and consuming relevant content.
  • To customize colors, change the CSS of screens by clicking the "Screens Style" button in the UI Builder. For more information on adjusting the visual appearance of Screen-Sets, see UI Builder: Responsive Design.

Registration Flow

The registration and login flows are essentially the same, and differ only in the first screen displayed to the user. The registration flow is initiated by calling:

	startScreen:'gigya-register-screen' //Specify the registration start screen, rather that the login one.

This calls the registration screen. The rest of the flow depends on user interaction: 

A simple registration flow includes the option to log in to an existing account, and registering with a social network. When a registration process completes successfully, the pop-up registration screen closes (unless you chose to embed the screen in a page) and the user is logged in to your site. In addition, an onLogin event is fired. You can use this event to create your login session cookie and redirect the user to a proper page. To register to this event use the accounts.addEventHandlers method. To learn about more SAP Customer Data Cloud events, see Events.

Note: By default, a session ends when the user closes their browser. To extend the session:

  1. Show the Remember me checkbox, enabling the user to extend the session indefinitely (or until they log out).
  2. Call accounts.setPolicies and pass gigyaPlugins {sessionExpiration: -2}. This will extend sessions indefinitely for all users.

Advanced Registration Flow

Depending on your implementation, several additional options may be triggered in a standard registration flow. The above chart illustrates these options: 

  1. Profile Completion: This screen is triggered when information is missing from the user profile. Make sure to include any relevant fields in the screen, or the user will not be able to complete their registration. For example, the screen may pop up in the following cases: 
    • If the user registered with a social network that is missing fields that are required in the schema. For example, email is a required field, but is not part of the user profile in Twitter, so a prompt asks the user for the minimal required data, without impinging the ease of registering with a social network. The user does not yet have a valid session when the screen appears as part of the registration flow. 
    • If your sites includes Customer Consent, the screen will appear in case the user is missing a valid consent to a required consent statement. If the user had an active session when this screen appears, that session is terminated. If the user closes the screen without agreeing to the mandatory consent statements (clicks the "X"), the user is logged out (accounts.logout and socialize.logout are fired). 
    • If any other schema field is required (mandatory) but the user has not entered its data. 
  2. Account Linking: Triggered if the user is attempting a first-time registration with a social network or by creating a new site account, but an account already exists for that user which they created with a different login method (e.g., the user is trying to create a new site account but that email is associated with an existing user account created by registering with a social network). For more information, see below
  3. Email Verification: If your site policy requires email verification to complete registration, this flow is triggered automatically when the user registers.  The flow includes a verification email that is sent automatically to the user. For more information, see Email Templates
  4. Forgot Password: In any registration or login scenario, the user can initiate a reset password flow

Risk-Based Authentication

If you have enabled Risk Based Authentication, users may be required to provide additional means of identification (two-factor authentication), or be forced to pass a CAPTCHA challenge before they can log in or register. Depending on you configuration, in some cases (such as multiple failed logins), they may be locked out of their account for some time.

The following diagram illustrates the registration flow when two-factor authentication (TFA) is enabled in your RBA policy:

TFA Registration (3).png


The following screen is an example of a user being asked to provide a second authentication factor: 

Login Flow

The registration and login flows are essentially the same, and differ only in the first screen displayed to the user. The login flow is initiated by calling:

	screenSet:'Default-RegistrationLogin' //The default start screen is login, so there is no need to specify it here.

This calls the registration screen. The rest of the flow depends on user interaction, and is identical to the registration flow shown above. 

Phone Number Login Flow

Users can log in or register using their mobile phones. A temporary code (one-time password, or OTP) is sent to their phones and used to authenticate them. If your site schema includes required fields, you have active consent statements, or a COPPA compliance policy, the Profile Completion screen will also be displayed. For more information, see Phone Number Login.

Lite Registration Flow

In a Lite Registration screen, the only data required by Gigya is a valid email address. This type of screen is usually used for subscriptions, and any flow where only an email address is required, such as competition sign-ups, unlocking restricted content, voting etc. For more information, see Lite Registration Required Fields.



Unable to render {include} The included page could not be found.


Update Profile Flows

These flows are initiated by users who wish to display and edit their profile info, or can be called if certain conditions are met, such as in a progressive profiling scenario. The update profile screen is initiated by calling: 


This displays the Profile Details screen: 

You can add fields to this screen and add additional screens to the Update Profile flow. 


Privacy and Communication Screens

Used in implementations of Consent Management, for displaying to users the consent statements and communication preferences to which they agreed. 

These screens are part of the ProfileUpdate screen-set. 


You can add a link between the screens by adding a link control in the UI Builder and selecting the relevant screen from the Properties pane.

Change Password

Change password flow:

Phone Number Update

For sites that allow phone number login, a flow can be triggered for changing their mobile phones. This causes a code to be sent to their new phones for verification. Once the new number is verified, their login phone number is changed. 

Verification Methods

If your site has Two Factor Authentication enabled, users may edit the device selected for authentication: 

  • Phone number to which verification codes are sent:
  • Time-based authentication: After re-authenticating, users may change their device (re-scan the barcode with an authenticating app), or print backup codes to be used when their device is not accessible: 

    On mobile devices, users may view their backup codes and generate new ones, but cannot print them.


Link Accounts Flow

Gigya recognizes that although the user is attempting a first-time registration with a social network or by creating a new site account, an account already exists for that user which they created with a different login method (e.g., the user is trying to create a new account with a social network, but their email is associated with an existing site account). 

The Link Accounts flow is initiated by calling:



This triggers the Link Accounts flow: 

If a user tries to create a new account with a different registration method from one that they used in the past, the link accounts screen-set presents two options:

  1. The user enters details of their existing account and the new account is linked to the existing account, which now includes both site registration data and social network data.  
  2. A new account is created (separate from the existing account). Two separate accounts co-exist in the database.

Note: This flow is initiated when users use a new registration method and can't be used to link registered accounts.

Re-Authentication Flow

Site administrators may want to enforce additional security when a user navigates to a sensitive area in the site, or is about to perform a sensitive operation (e.g. purchase an item). A useful option is to invoke a re-authentication dialog that requires the user to prove ownership of the account in use by logging in again to proceed.

The Re-Authentication flow can be invoked at any point by calling: 

	screenSet:'<Your Re-authentication screen-set ID>'

This displays the Re-authentication screen. The rest of the flow depends on user interaction. 


The re-authentication process succeeds if the credentials entered are correct and represent an identity associated with the user on the site.
If a user successfully enters credentials of a user identity that is not associated with the user, re-authentication will fail.
In any case, the user will not be logged out as a result of a failed re-authentication.

Handling the Result

In order to know whether the re-authentication process succeeded, developers have a couple of options:

  1. Register to the onHide event callback when calling account.showScreenSet.


    //Function that handles the re-authentication result
    function handleResult(eventObj) {
        if (eventObj.reason == "finished"){
            alert ("Re-Authentication successful!");
        else if (eventObj.reason == "canceled"){
            alert ("Re-Authentication failed :(");
    // Load screen-set
    var params={
        screenSet: "Default-ReAuthentication",
  2. Listen to the global onLogin event and check the loginMode parameter to see whether this was a re-authentication. This is done using the socialize.addEventListener function.

    function isReAuth(eventObj) {
        if (eventObj.loginMode == "reAuth"){
            alert("User has re-authenticated!");


Forgot Password Flow

The forgot password flow is initiated by the user, when he clicks the "Forgot Password" link on one of the screens that includes this link. Alternatively, you may initiate this flow by calling:


This displays the forgot password screen. The rest of the flow depends on user interaction. 

When the user submits the Forgot Password form, we send a Password reset email to the user. The email includes a URL link to a page where the password can be reset. The default URL is: https://<your CNAME>/newPassword (a default change password page provided by Gigya).

The easiest and recommended best practice, however, is to use the Reset Password screen of the SAP Customer Data Cloud Screen-Sets. For instructions on implementing the Reset Password screen see Email Templates and editing the default URL to the page hosting your Reset Password screen.