SAP Customer Data Cloud Positions

Screen-Sets

Skip to end of metadata
Go to start of metadata

Introduction

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 in the following ways:

  • 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. 
  • Change the user-facing error messages. For more information, see Customizing Screen-Set Error Messages.

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.

Screen-sets are displayed on your page after loading the Gigya SDK, by calling accounts.showScreenSet. See below for code samples.

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.

Accessibility

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 Flows

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:

gigya.accounts.showScreenSet({
	screenSet:'Default-RegistrationLogin',
	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: For more information, see below
  4. Forgot Password: In any registration or login scenario, the user can initiate a reset password flow

Email Verification

You may configure your site policy to require email verification after a user completes their registration. In the policy configuration, one of the following verification options may be selected:

  • Link
  • Code

Only one option may be selected, not both. Both verification flows will send out an email automatically, using the email verification template.

The different verification methods result in different verification flows:

Email Code Verification Flow

 

When using the email code verification flow, note the following:

  • The flow uses the Verify New Email screen in the registration-login screen-set.
  • The email provided by the user will be saved to the profile.email field.
  • The recommended best practice is to set the profile.email field permissions to server-only, to enforce the use of the verification flow.
  • After the user submits the code, the email is considered verified, the account becomes a verified account and relevant timestamps are updated accordingly.
  • See below for an email update flow using a verification code. 
  • The email template associated with this flow is the Code Verification template.
  • The email code verification flow uses the following APIs: 

Limitations 

The following limitations apply for email code verification screen-set implementations:

  • There is a 10 seconds wait between consecutive requests for a verification code.
  • Up to 5 code requests are allowed per email in a 5 minutes window.
  • After 5 code requests that do not complete (no successful verification), there is a 5 minute cool-down period (no logins allowed for that email).
  • To minimize risk,the system validates that the device that requested the code is the same device used for logging in.
  • The code is valid for 5 minutes.
  • Like in other login flows, additional user data cannot be saved in an email verification flow (i.e., you cannot add input fields to the email verification screen, or change existing field mappings).

 

Email Link Verification Flow

  • This flow uses the Verification Pending and Verification Sent screens in the registration-login screen-set.
  • The email template associated with this flow is the Email Verification template.

 

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

 

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.

 

Lite Account Progression

You may use the Lite Account Progression screen for converting a lite registered user to a fully registered one. For more information, see Lite Account Progression. The screen is located in the RegistrationLogin screen-set in the UI Builder.

This screen is used in the following flow:

  1. Lite user receives an email prompting them to create a full account on your site.
  2. Lite user clicks an email link that redirects to a page of your site that hosts the Lite Account Progression screen or the Lite Preferences Center.
  3. The redirect link should include a registration token in the following format: "gig_regToken= 123456". If the email uses the Lite Preferences Center email template, the token is passed automatically.
  4. The account progression screen parses the email from the token and requests a password from the user.
  5. After the user submits a password, a full account is created with their email address, and any additional information present on the screen.
  6. If your site policy is set to require email verification, the user will then receive a verification email. After verifying their email, the information stored on their lite account is copied over to their full account. Note that if the user provided data (e.g., first name) on the account progression screen that is different to what they previously provided, the data inputted on the account progression screen will be saved (i.e., the full registration information is "stronger" than the lite).
  7. The user can now log in with the email they used and password they created.

 

The account progression screen is a full registration screen, therefore any fields that are required in the schema should be visible on this screen. If they are not, a "Registration Completion" screen will pop up after the user submits the account progression screen.

 

Login Flows

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:

gigya.accounts.showScreenSet({
	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. 

Note that you cannot save data to a user account in login flows; they are used only for authenticating the user. 

Phone Number Login

A passwordless login flow, that saves users the need to remember complex passwords: 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.

Push Authentication

A passwordless login flow, that saves users the need to remember complex passwords: Following their registration, users can opt in to a push notification flow, authenticating by approving a pop-up on their mobile phones. For more information, see Push Authentication:

Push Authentication includes 4 screens in the RegistrationLogin screen-set: 

Passwordless Login: Includes a login identifier field (currently supports email or username) which the user submits. 

  • When no authentication methods are associated with their account, the next screen is Auth Methods

  • If they do have an authentication method, the relevant Password Auth or Push Notification Auth screen opens. If they have both methods, the latest authentication method is used.

Auth Methods: If no authentication method is saved to the user's account, they select the method on this screen. 

Password Auth: If the user chose to authenticate with a password, they can enter it here. 
Push Notification Auth: If the user chose Push Notfications, this screen opens and checks periodically to see if the user has approved the push notification on their app. Once the user approves, this screen disappears and the user is logged in. 

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: 

gigya.accounts.showScreenSet({
	screenSet:'Default-ProfileUpdate',
});

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. 

Email Update

If your site policy requires email code verification, use this flow to allow users to update their email address. Users will receive a code to the new email and be prompted to enter it in a new screen.

To enable this flow on the Profile Update screen:

  1. Login to the Console and navigate to the Screen-Sets page, and open the Profile Update screen-set, on the Update Profile screen.
  2. Drag a Label control into the screen from the left-hand Controls menu. This will display to the user their existing email, as well as a link to change it.
  3. Under Properties, edit the label, in the following structure: {{profile.email}} <a data-switch-screen="gigya-change-email-screen">Change</a>. Explanation: 
    • {{profile.email}} displays to the user their existing email.
    • The <a> tag creates a link, in this case with the text "Change". Edit this text as needed.
    • The link itself is an internal link that opens a different screen from within the update profile screen, using the internal name gigya-change-email-screen.
  4. Save your changes.
  5. This flow also uses the Change Your Email screen in the registration-login screen-set, so you can edit that as necessary.

The email template associated with this flow is the Code Verification email template.

 

Second Factor Authentication Flows

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:

gigya.accounts.showScreenSet({
	screenSet:'Default-LinkAccounts'
});

 

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

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

-  You cannot save data to a user account in an account linking flow

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: 

gigya.accounts.showScreenSet({
	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.

You cannot save data to a user account in a re-authentication flow.

 

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",
        onHide:handleResult
    };
    gigya.accounts.showScreenSet(params);
  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!");
        }
    }
     
    gigya.socialize.addEventHandlers({
    	onLogin:isReAuth
    });

 

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:

gigya.accounts.showScreenSet({
	screenSet:'Default-RegistrationLogin',
	startScreen:'gigya-forgot-password-screen'
});

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.