Skip to end of metadata
Go to start of metadata


Gigya 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 flows are 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 Gigya's Markup Extensions.
  • Change the flows and add new screens by manually editing the HTML and CSS code provided by Gigya. 

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 Gigya.

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

If you have a Gigya Academy membership, you can watch instructional videos about this and other Gigya products. To access Gigya Academy content, you should first make sure you are logged into the Gigya Console

Gigya Academy is a premium product that requires separate activation. If it is not part of your site package, please contact your Account Manager or contact us by filling in a support form on our site. You can also access the support page by clicking "Support" on the upper menu of Gigya's site.

To watch a video about Screen-Sets, Gigya Academy members can use this link (the entire series, and specifically video 2 of 14).


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 Gigya'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 Gigya 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, Gigya fires an onLogin event. 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 Gigya 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 may be triggered in the following cases: 
    • If the user registered with a social network that is missing fields which Gigya requires. For example, email is a required Gigya 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). 
  2. Account Linking: 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 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.  
  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. In some cases (such as multiple failed logins), they may be locked out of their account for some time. 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. 

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.


Update Profile Flow

This flow is 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 flow 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. 

A sub-set of the Update Profile flow screen are the Privacy and Communication screens. These are used in implementations of Consent Management, for displaying to users the consent statements and communication preferences to which they agreed. 

Additionally, users are able to update their password, and if your site has TFA enabled, users may edit the phone number they receive verification codes to. The screens that pertain to these flows are below.


Phone number change when TFA is enabled.


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 RaaS Reset Password screen of Gigya's 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.