SAP Customer Data Cloud Positions


Skip to end of metadata
Go to start of metadata


The Policies page in the Settings area of the SAP Customer Data Cloud Console allows the site administrator to define various site policies. 

Note: This page provides a user-friendly interface for specifying the most significant site policies. The extended list of site policies may be accessed through the usage of the accounts.setPolicies  and  accounts.getPolicies  API methods.

Registration-as-a-Service (RaaS) is a premium platform that requires separate activation. If RaaS is not part of your site package, please contact Gigya by filling in a support form. You can access the support page by clicking Support on the upper menu after logging into your Gigya Console.

Watch an Instructional Video

If you have an SAP logon, you can watch an instructional video about site policies here.

Policies Configuration

The Policies page may be accessed by clicking Settings in the upper menu and then Policies in the left menu, or opening this link when logged in to the Console.



Login Identifier

Select the preferred login identifier for your users; the options are Email, Username, or both.  If you select both, your users can choose whether to use their email or username for logging in:


The system-defined default screen-sets are designed to work only with Email as the Login Identifier, which is the default setting. Changing the login identifier setting requires you to add a user name field to the default screen-sets or to create your own screen-sets if the screen-set was created prior to October 26th, 2015. The Login Identifier of Screen-Sets created on or after October 26th, 2015 can be set to use Username by selecting that option from the Properties window of the LoginID widget. The LoginID widget is only applicable on Registration screens. Screen-Sets can be created or updated using the Screen-Set UI Builder. 

The system does not allow duplicate Usernames or  Emails.


Link Accounts Support

Set whether account linking is required when a user enters the system with an unregistered social network, which shares an e-mail with a registered account.

  • Disabled - The accounts are not linked: a new (separate) account is created in which the email is not used as a login identifier.
  • Site identities only - (Default) The user will be prompted to link the social network to an existing account which uses the same email as a login identifier, only if that account is a registered site account (not created by a social network login). The user can choose to create a new unlinked account which will not use the email as a login identifier. 
  • All identities - If any account on the system uses the email entered by the user as a login identifier, the user is prompted to link the social network to that account. The user can choose to create a new unlinked account which will not use an email as a login identifier.
    NoteWhen enabling social-to-social account linking (by choosing the 'All identities' option), the corresponding screen-sets must be created to support account linking. Make sure that these are created as part of the default screen-sets schema, or create them if necessary. Any Sites or Screen-Set Collections created after September 15th, 2014, have the necessary screens created by default.


Default Login and Registration Screen-Set

Select the default "RegistrationLogin" screen-set you wish to use in web and mobile.  

The screens of this screen-set may be displayed when the SAP Customer Data Cloud logic recognizes a potential error that can be solved by displaying an automatically triggered screen. It will not necessarily be displayed when the user is already in a screen-set flow. For example: 

  • In an SSO setting, where site A and B are part of the same site group and SSO segment, site A has a "last name" field set to required, and site B does not. The user registers to site B without providing a last name, and then navigates to site A. The server attempts to log them in automatically, but is missing the required field. In this case, the Registration Completion field of the screen-set specified here will be displayed. 
  • Your policy requires users to verify their registration via a verification email. After verification, a user is missing a required field, and again the Registration Completion screen that belongs to this screen-set is displayed. 

The screens of this screen-set will not necessarily be displayed in the following scenario: 

  • A user registers via the social login widget that is built into SAP Customer Data Cloud's registration screen, and therefore is missing a field that has been set to "required". The Registration Completion screen that will be displayed is the one that belongs to the same screen-set used for registering the user. 


For more information, see Screen-Sets.

Note: When using site groups, Child sites automatically inherit default screen-sets from their master site. To override the default screen-sets per child site, select 


Email Verification

When the user registers to a site that requires email verification, they are sent an email to verify their address. The email can contain a verification link, or a code. You can configure either a link or a code verification policy, not both (see below for more information).

Once Require Email Verification is enabled, you must ensure users are able to complete registration. To do this, you must first ensure that you have an email field on the Complete Registration screen of your site's Screen-Set, and that this field is set as Required in the site's schema. If you are using SAP Customer Data Cloud Default Screen-Sets, you can accomplish this by opening the Complete Registration screen in the UI Builder, selecting the Email field and checking the Required checkbox under the Schema tab of the Properties menu. Not doing this will result in users being unable to complete registration if their social network does not provide an email address, e.g. Twitter.


You can specify the format of the verification email using the Email Templates  page the Console. For more information, see Email Templates.

Note that SAP Customer Data Cloud validates all email addresses per RFC 822 as a minimum requirement, regardless of any custom regex, which will be checked in addition to the RFC.


Note: When using site groups , Child sites automatically inherit email verification policy from their master site. To override email verification settings per child site, select 

For more information regarding the SSO implications of overriding email verification settings when using site groups, see SSO - Member Site Policy Override.

Link Verification

The link appearing in the verification email automatically redirects to the landing page, which in turn, finalizes the registration process and logs the user in to the site.

Check Require email verification to activate this policy, and make sure Use code verification isn't selected:

Email link verification is done by sending a verification link to the email address registered to the user.

Link Verification Configuration Options

The following options are available once email link verification has been selected:

  • Require email verification after social login -  Requires social login users to verify their email addresses. If this option is not selected, the email associated with a social login account will be considered verified. 
  • Customize redirection URL - The page to which the user will be redirected after verifying their email.
  • Customize verification link expiration time -  The number of hours that verification emails are valid.
  • Automatically login users upon email verification -  When selected, users will be logged in automatically once their email address is verified.
    • When this option is selected, you must specify a customized redirection URL (i.e., a landing page) on your site to handle the logged-in user. The landing page must contain the SAP Customer Data Cloud Javascript library, and will automatically fire the onLogin global event. See Policies - Advanced for more information.

Activating Automatic Login

In order to use the Automatically login users upon email verification option, make sure to specify a Customize redirection URL and that the Automatically login users upon email verification option is selected in the site's Policies.

The page to which the user is redirected must contain a reference to SAP Customer Data Cloud's Javascript library. In addition, the onLogin event is automatically fired and may be used in your client-side code.

A sample html page can be found below.

<!DOCTYPE html>
<!-- -->
<title>Email verification custom landing page</title>
    <!-- gigya.js script should only be included once -->
    <script type="text/javascript" src="[YOUR_API_KEY]"></script>

<script type="text/javascript">

// This function is called when the onLogin event is fired
function loggedIn(){
document.getElementById('successDiv').style.display = "";
document.getElementById('successDiv').innerHTML = "This is awesome, I am already logged in!";

// Register for Login event
gigya.socialize.addEventHandlers({ onLogin: loggedIn });

<div id="successDiv" style="display:none">Logged In!</div>


Code Verification

When turning on code verification, users will receive an email with a code after submitting the registration screen. On the next screen, they are required to enter that code. To enable this policy, make sure Use code verification is selected together with Require email verification

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 field.
  • The recommended best practice is to set the 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.
  • This policy also includes an email update flow, that uses the Change Your Email screen of the registration-login screen-set.
  • You may Require email verification after social login -  Requires social login users to verify their email addresses. If this option is not selected, the email associated with a social login account will be considered verified. 

For more information, see Email Verification.

Double Opt-In

If your implementation includes Subscription Management, and your subscriptions require double opt-in, you can perform the following configurations in the Policies page of the Console:

  • Customize redirection URL: The URL to which subscribers will be redirected after successfully confirming their subscription. Note that upon successful confirmation, SAP Customer Data Cloud automatically appends to the query string of the URL a comma-separated list of subscription IDs. You can use this list to add custom code to your page that references these subscriptions (e.g., "Thank you for subscribing to newsletters A, B and C")
  • Customize confirmation link expiration time (hours): The length of time (in hours) for which the confirmation link is valid.

Multiple Login Attempts

Multiple failed login attempts are now configurable via RBA, for additional information, see Risk Based Authentication.


Authentication Types

The types of authentication you allow users to use on your sites. 

  • Password authentication is always enabled
  • Push notifications allow your users to authenticate with a notification sent to their mobile phones. When enabling this policy, also enter the Firebase server key for your Firebase project. For more information, see Push Authentication

Password Strength

The password strength is defined by:

  • Min Length - minimum number of characters
  • Min Character Groups - the number of the different character groups that must be included in the password. The character groups are: capital letters, lowercase letters, numbers and special characters.
    For example:
    If you define "Min Character Groups: 3", it means that a password should include at least three different types of characters. In such case, the following passwords would meet the requirement: Fcc3d1, YH*77P. And the following passwords would not meet the requirement: hwi654yy, 6FG5VV because they only include 2 character groups.
  • Regular Expression -  an alternative/additional way to specify password strength is by defining a string pattern that the passwords must match.
    Supported regEx syntax can be found here.

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

Password Change

In this section you may choose whether the password should be changed, and if so, after how many days. 

You can also decide to forbid reusing a specified number of previous passwords. Regardless of this setting, the password can never be reset to the current one.


SAP Customer Data Cloud will remember the previous 7 passwords for the Forbid reusing any of the previous X passwords field.

For additional information on the password reset email, see Email Templates.


Age Limit - COPPA Compliance

SAP Customer Data Cloud supports forcing age restriction in compliance with COPPA rules. Enable this option to apply COPPA compliance and force a minimum age limit on new registered users to your site:

By default this option is disabled. When enabled, each time a user registers with your site, SAP Customer Data Cloud will check their age. Users must be 13 years +1 day old (to guarantee compliance due to time-zone variations) to register for your site. If they don't meet the minimum age requirements, they are prompted with the message "Your age does not meet the minimal age requirement (13+) for this site", if you are using our client-side tools (UI Builder/Markup Extensions).
If you are using direct server-side API calls (i.e., accounts.register) you will receive the following error in the response: "Underage user" (error code: 403044). For more information, see Identity Compliance.

If COPPA is enabled, it is important that all Registration/Registration Completion screens contain the necessary birth date fields, if a user is unable to provide their age, the user will be unable to finalize and complete their registration.

If a user enters a birth date in the future, the following error will be returned:

  • errorCode: 400006, errorDetails: "Birth date must be in the past.", errorMessage: "Invalid parameter value"


Additional Security Measures

Choose whether additional security measures should be employed when users register to your site. 



A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is an identification procedure used to ascertain that a registration attempt is made by a human and not a robot. 

SAP Customer Data Cloud implements Google's Invisible reCAPTCHA freeware. This means that the CAPTCHA component is an unobtrusive part of the registration screen, and triggered only if Google's algorithms identify a cause for suspicion, in which case the user will need to prove that they are human: 


Implement CAPTCHA in registration screens according to the following guide: CAPTCHA

To ensure proper registration form validation, be sure to include the CAPTCHA widget in every registration screen.

Account Harvesting

Login identifier harvesting, also known as account harvesting, is the process of grabbing legitimate user IDs to gain access to target systems for illegal or malicious purposes. You can protect against login identifier harvesting by enabling this option.

When enabled, new users will not be notified if a requested log-in ID already exists, while existing users entering an incorrect password will receive an "Unauthorized access error".
Because of its detrimental impact on user friendliness, this option is disabled by default.   

If you enable this option, the following API methods change their behavior:

  • The gigya-loginID-availability widget does not function, preventing new users from easily checking the availability of user IDs.
  • The accounts.getConflictingAccount method always returns a "Not supported" error. This means that you will no longer be able to link accounts.
  • The accounts.isAvailableLoginID method always returns an "Unauthorized access error" (code 403026).
  • The accounts.resetPassword method returns error code '0' (indicating success), even when the loginID passed with the method does not exist in the system or the email address is improperly formatted.
  • If a site account already exists and the user subsequently logs in with a social provider using the same email address, the accounts will not be linked and the socialize.login method returns error code '0' (indicating success) and creates a new account which does not use the email address as the login identifier.
  • The accounts.register method**:

Regardless of this setting, the Login screen (from the RaaS screen-sets) always displays a generic error message when a login ID doesn't exist and/or a password is incorrect.

** accounts.register is used whenever an account is created, i.e., importing accounts, so this same error will also trigger when using any import APIs.

Account Harvesting Via Account Update

Sometimes, account harvesting may be attempted by logged in users attempting to change the email identifier of their account. You may protect against account harvesting attempts by doing the following: 

Enable the following policies: 

  • Protect against login identifier harvesting
  • Require email verification > Use code verification

In the Schema Editor, set the field to be Required, with a Write Access of serverOnly.

In the UI Builder, for both Registration Completion and Profile Update screens: 

  • Set the email field to read-only
  • Add a link to the "change your email" screen

These steps will ensure that users must confirm their email via code verification when they update their profiles, and cannot use this flow for account harvesting. 

Automated Emails


Note: Before automated emails can be enabled, templates must be defined for the relevant emails. For instructions on template definition see here


  • New user welcome - When enabled, a mail is sent after the user successfully completes registration. On sites where verification is required, the mail will only be sent after successful verification.
  • Password reset confirmation - When enabled, a mail is sent after the user successfully resets their password, note that this is a confirmation email, and differs from thePassword Reset mail sent to a user who has forgotten their password.
  • Account deletion confirmation - When enabled, a mail is sent after the user successfully deletes their account. 

Email verification emails are enabled above


Account Progression

When implementing Lite Registration, you can decide how to handle lite user data, when a user progresses from a lite to a full account. For more information, see Lite Registration.

Two-Factor Authentication

TFA configuration is no longer set via site Policies and is now available as part of Risk Based Authentication.


Site Policies and SSO

You can override certain policies configured for the master site, in individual sites in a site group. 

To override master configurations for a child site:
  1. Go to the Policies page for the relevant child site. 
  2. Check the Override master settings checkbox for the relevant configurations (e.g., Additional Security Measures).
  3. Click Save Settings.

These are the only settings that can be overridden by a child site: 

  • Default login and registration screen-sets
  • Email verification
  • CAPTCHA requirement for new registrations
  • The sending of the following automated emails: 
    • New user welcome
    • Password reset confirmation
    • Account deletion confirmation

Some policies can only be activated or disabled on the master site, but can be fine-tuned on each member site.

For information about the parameters that can be overridden when using the REST API, see the following pages.

accounts.setPolicies REST

accounts.getPolicies REST


Advanced Policies Configuration

It is important to note that any time you make a field required in the site schema, you must include a field for the item within the Registration Completion screen of your site's Screen-Sets. Failure to do this will make it impossible for some users to register with your site.


While the Console provides you with certain built-in policy schemas and options, these policies can be further customized using the accounts.setPolicies REST API. 

The API allows for a greater range of flexibility when customizing site policies.

Additional Customization

Please refer to the complete Accounts REST API documentation for all possible api methods available.