Getting to Know the Enhancements and Features

Permissions Groups streamline the administration of user and application access and control across the platform, ensuring that only authorized individuals and applications can handle specific features or access particular datasets.

Permissions Groups serve as collections of users and applications granted specific access rights based on their roles, thus offering a structured approach to manage permissions. Administrators can assign users or applications to multiple permissions groups within the same partner, with the highest level of assigned permissions taking precedence. The permission structure ensures that the most comprehensive access level granted to a user will apply, greatly simplifying user management and reducing the risk of unauthorized access.

Detailed management of privileges – which encompass the specific capabilities assigned to each group – is facilitated through the Privileges tab within the Console. This tab provides a centralized view of all available privileges, allowing easy enablement or disablement for the selected group. Privileges are categorized for better organization, and they directly map to the allowed API methods. This mapping ensures transparency and ease of privilege management, enabling administrators to precisely control what each group is permitted to access and operate.

From the Console, administrators have comprehensive control over permissions groups. They can create new groups, delete or remove existing ones, and manage the membership of each group. The Privileges tab displays all the available privileges and allows the admin to enable/disable privileges for the specified group. Privileges are divided into categories and are mapped to allowed API methods. In the Privileges section, you can search for a specific privilege or see the list of categories and full mapping of privileges to APIs.

You can now exercise more granular control over who and what apps can access to the System Cross-domain Identity Management (SCIM) APIs. SCIM APIs no longer require the _admins permissions group, this enhancement eliminates the previous requirement for the _admins permissions group, streamlining authorization processes and extending flexibility in user management. By assigning either the SCIM API Access or the Full API Access to specific users or applications, administrators can fine-tune who and what applications can interact with SCIM APIs.

This improvement significantly benefits organizations by enhancing security and simplifying the management of API permissions. You can now delegate SCIM API access without broadly expanding administrative privileges, ensuring that users or applications have the precise level of access required for their roles. This update not only bolsters data protection but also optimizes compliance with best practices in identity management and access control within your organization.

The Log Connector tool allows you to expose your log data and send it to specific log providers in a way that enables you to use this log data in platform-related monitoring and correlate your CIAM flow with other application metrics.

The Log Connector sends the log information for all sites in a partner. If you want to sort the data when it arrives, you can use the API keys of the sites in the payload.

PII (personal identifiable information) fields are not sent, so that no sensitive information is exposed.

The information that is sent includes API keys, endpoints, error codes, and timestamps.

The Log Connector now features two new parameters: cid and authType, both allowing for the transmission of additional contextual data in your CDC API calls. These additions are designed to enhance the granularity and contextuality of data captured in your application logs.

The cid parameter allows you to transmit customer identification data within your CDC API calls. This enables more detailed monitoring and tracking of customer interactions, supporting better insights into individual behaviors and activities. Concurrently, the authType parameter facilitates the transmission of authentication type information. By incorporating these parameters, your logs can now provide a clearer understanding of how users authenticate, whether through social logins, single sign-ons, or other methods. These improvements collectively contribute to more customized and informative monitoring, ensuring you can make data-driven decisions with greater precision and confidence.

Example CDC Log entry for a login API call:

12345678910111213141516171819202122232425262728
[
   {
      "Timestamp":"2024-10-11T06:14:28.4280000Z",
      "Level":"Information",
      "MessageTemplate":"{endpoint} called on partner {partnerID}",
      "RenderedMessage":"\"accounts.logout\" called on partner 95103036",
      "Properties":{
         "apikey":"4_xuJS8yk2DSZqmIJmBrzC3Q",
         "callID":"45b37cd1304b4627a05d937337246548",
         "timestamp":1728627268428,
         "duration":58.634,
         "endpoint":"accounts.logout",
         "errCode":0,
         "partnerID":95103036,
         "country":"US",
         "referrer":"https://cdns.us1.gigya.com/",
         "SDK":"js_latest",
         "ip":"121.130.84.199",
         "type":"request",
         "errMessage":"OK",
         "riskScore":0,
         "uid":"ed2db3eaa14644cf881dfd7bf98a1623",
         "authType":"loginToken",
         "userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36",
         "timestamp_iso":"2024-10-11T06:14:28.428Z"
      }
   }
]

For the complete list of fields sent from the CDC to the log providers, please refer to: Data Sent to the Log Providers

You can use the Email Providers page to configure one or more SMTP servers to send your SAP Customer Data Cloud emails from instead of the default gigya-raas.com domain. This is useful in cases when you need to send SAP Customer Data Cloud emails to your users from your own domain name and not the SAP Customer Data Cloud server.

Email domains are stored at the Tenant level, so any email provider configured here will be available to all sites and all partners that are within the same SAP tenant.

It is important to not update any email templates in the console until after the SMTP server is configured and tested.

The Email Provider Alerts feature is designed to help you proactively manage and resolve issues with your configured email providers. With this feature, you can enable alert notifications that are triggered whenever errors are returned from a partner-configured Email Provider. This ensures that you are immediately informed of any problems, allowing you to address them quickly and minimize any potential impact on end users.

To take advantage of this feature, you can enable email notifications for each configured email provider in your account when problems are detected from the provider. Simply go to the Email Providers page, select the desired email provider configuration, and choose Edit. Locate the Alert Notifications section near the bottom of the page, where you can configure the Error Threshold and assign at least one email address to receive the alerts. The Error Threshold is a parameter that defines the number of email failures allowed within the previous 6 hours before a notification is sent, and it can be set to any integer between 1 and 65,535. By fine-tuning these settings, you ensure timely notifications, which helps you maintain high levels of service availability and user satisfaction.

For sending SMS with voice message support to your end users, you must configure an SMS Provider.

Apart from other SMS Providers, you can configure Twilio to send SMS or voice messages.

When Twilio is selected, you will gain access to another section in the configuration named SMS Sender. This is where you can configure a default number for any Provider Type as well as add country-specific numbers if you want SMS or voice calls to come from a number local to the end user.

The Twilio Country-Specific Voice Message Support feature empowers you to offer end users the choice of receiving voice messages instead of SMS. By toggling the Optional Voice Setup option, you can easily configure this feature to ensure seamless communication with your users via voice calls.

To set up, start by adding the default phone number from which all voice calls will originate. If you need to use multiple voice numbers specific to different country codes, you can click on the corresponding link to add Country Specific Numbers and enter the necessary details. This allows you to configure a unique number for each country, ensuring that users receive phone calls from a local number. This feature not only enhances the user experience by providing familiar and localized touchpoints but also helps in achieving higher engagement and response rates. By leveraging Twilio's robust infrastructure, you can now offer a more versatile and user-friendly communication channel tailored to the preferences of your global customer base.

When CIAM for B2B is enabled, this feature introduces an additional option within the Relying Party (RP) configuration screen, allowing you to link the RP to a B2B application seamlessly. By selecting from your existing B2B applications in the provided dropdown, you can easily associate the RP with the appropriate B2B application. This association is facilitated through the B2B AppId, which is the unique identifier of the B2B Application linked to the OIDC OpenID Provider (OP).

The B2B AppId can be located in the ClientID field under the Applications tab in the Organization Management console.

Additionally, you can specify Custom Scopes within the RP configuration. These are optional, space-delimited, case-sensitive list of additional scopes preconfigured on the OP that you are authorized to request from OP. Entering these scopes in the Custom Scopes field grants the RP access to specific data relevant to these custom scopes. If the Custom Scopes field is left empty, the RP will have no access to any available custom scopes or the data they encompass.

This feature not only enhances the precision with which you can manage access but also adds a layer of customization, empowering you to tailor the RP configurations to your specific business needs.

The OIDC for B2B feature allows you to configure Business-to-Business (B2B) applications as OpenID Connect (OIDC) Relying Parties (RPs) directly from the main SAP Customer Data Cloud application, alongside other OIDC RPs. By integrating B2B applications in this manner, you can map B2B-related claims within the OIDC ID token, enabling a broader array of claim mapping options, including the mapping of Organization and Authorization data. This data can be added to custom scopes within the OIDC OpenID Provider (OP) settings, thereby providing more precise and tailored authentication experiences for your users.

Claims in OIDC represent information asserted about a user, such as their first name or phone number, while scopes define the type of data to which RPs are granted access.

To fully leverage this feature, you can add additional custom scopes and/or claims for your OP. Before creating a custom scope, it is essential to first define the claims that will be included within that scope. These claims can be mapped to any available account field including profile data, customIdentifiers, and B2B organization data (excluding samlData).

Once you have defined your claims, you can then proceed to define any necessary custom scopes and map these scopes to the appropriate custom claims, these scopes/claims will be available for use when configuring RPs. This setup allows for a highly customizable and granular approach to managing authentication and authorization for B2B applications, ensuring that your enterprise authentication strategies are both robust and flexible.

The email or SMS invite options in the B2B Delegated Admin console is managed through the email and/or phone member attributes in the Member Attribute settings, giving you increased control over how invitations are sent to new members. By customizing these settings, you can ensure that only the desired communication channels are available for your B2B administrators, thereby streamlining the user invitation process.

To access and modify these settings, navigate to the Member Attributes tab within the Organization Workspace Settings. Here, you will find a list of currently defined attributes used to characterize each member. By selecting an member attribute from the Attributes List, you can view and edit its details and the setting configurations for that attribute under the General, Attribute Management Settings, and Attribute Usage Settings sections.

In the Attribute Usage Settings, you will find the following options:

• Use for Email Notifications
• Use for SMS Notifications
• Can be used in Policies
• Can be used in Access Request
• Name of Request

The Use for Email Notifications setting determines whether the attribute can be used for email notifications. Note that each member can have only one email field designated for notification purposes, and at least one email or SMS field must be set for notifications. If no field is set for email notification, the invite by Email option will not appear in the delegated admin console.

Similarly, the Use for SMS Notifications setting determines if the attribute can be utilized for SMS notifications. Each member can only have one SMS field for notifications, and at least one notification field (email or SMS) is required and must be set to use for notifications. If no field is configured for SMS notification, the invite by SMS option will be absent from the delegated admin console.

This flexible configuration ensures that the invitation process aligns with your organization's communication preferences and policy requirements.

The introduction of OnBeforeSetAccountOrganizationInfo extension endpoint allows for synchronous validation use cases when updating an account's relationship to an organization, such as inviting a user to an organization or assigning a policy to an account.

This extension point is triggered by the accounts.b2b.inviteMember and accounts.b2b.setAccountOrganizationInfo REST API calls.

The OnBeforeSetAccountOrganizationInfo endpoint is invoked after SAP Customer Data Cloud completes all its required validation checks for setting the account organization, but before the account organization is actually set. This timing ensures that any custom validations you implement have the final say in whether the account organization update proceeds. If the extension returns an error, the request will fail, preventing the account organization from being set.

This enables you to perform additional custom validations on the incoming data, ensuring that any organizational changes meet your specific business rules and compliance requirements.

The extension endpoint's response guides SAP Customer Data Cloud on how to proceed with the update account organization info or invite member process.

Using the status field, your extension can indicate:

• OK: The account organization info was validated successfully by the extension point, and processing of inviting organization member or account organization info update can continue.
• FAIL: Processing of inviting organization member or account organization info update should cease, and an error message will be displayed.

SAP Customer Data Cloud expects to receive responses in the above structures from the extension URL, along with unique parameters specific to this extension type and the common payload that you can expect to receive from SAP Customer Data Cloud, followed by the full structure of the post request.

This feature enhances your control over data integrity and adherence to business logic, providing a robust mechanism to ensure that all account-organization relationships are validated to your standards before they are set.

When you load the Web SDK via a custom domain, the Web SDK will now load all resources via that domain. This enhances site compatibility with newer browsers by addressing domain issues with cookie and resource blocking.

This enables the Web SDK to use the domain that it was loaded from to also load all SAP Customer Data Cloud resources, i.e., https://<your-domain.com>/js/gigya.js?apiKey=<Your-API-Key>.

As newer browsers are starting to block 3rd party cookies and resources, it is recommend to always load our Web SDK (gigya.js) via a CNAME. When you load the Web SDK over a CNAME, then all resources used by the Web SDK will be from your own domain (the CNAME) and will avoid any 3rd party blocking issues. When using the Web SDK over a CNAME, the only file that will still use the gigya.com domain is the user's profile photo URL.

An example of adding the gigya.js Web SDK script tag to your pages:

12
<script type="text/javascript" lang="javascript" src="<YOUR-CNAME-ALIAS-TO-Gigya>/js/gigya.js?apiKey=<A_Valid_API_Key_For_Your_Site>">
</script>

You can now preload screen-sets, separating content retrieval from activation of the screen-set. This gives you improved efficiency with reduced loading times and optimized user experience.

accounts.loadScreenSet JS

This method allows a screen-set to be loaded without displaying it, for cases when you wish to display the screen-set at some later time.

This API separates content retrieval from activation of the screen-set, giving you improved efficiency with reduced loading times. At any later time you can call accounts.showScreenSet JS, and the loaded screen-set will be displayed immediately, without any latency.

This sample loads the Default-RegistrationLogin screen-set:

123
gigya.accounts.loadScreenSet({
            screenSet: 'Default-RegistrationLogin',
          });

The accounts.importFullAccount REST endpoint now supports importing phone numbers as part of the user's account information, communications topics and guest identities.

The phone number imported acts as an account identifier, and may be used to support phone login scenarios.

accounts.importFullAccount REST API

This method imports user account data into the Accounts Storage. Imported users are not considered new users for reporting purposes.

• phoneNumber

  This parameter is the phone number login identifier, if the account uses Phone Number Login. The supported phone number formatting is E.164.

• Communications

  This parameter is the user's communication information. The object includes information on the user's communication topics.

• Identities

  This paramerter is the user's identities information. Contains all the properties of the Identity JS object.

On the screenshot, the phoneNumber parameter value is URL encoded, the original E.164 value is +11255543556.

A new interaction object has been added to the webhook payload, specifically for the accountUpdated event.

This enhancement is designed to improve your integration capabilities with third-party systems by offering deeper insights into the nature of the interactions that trigger account updates.

The interaction object, which is part of the event data object, contains a type property that indicates whether the accountUpdated webhook event was triggered by a lite interaction or an authenticated interaction. This distinction is crucial for understanding the context of the account update, allowing third-party systems to respond appropriately based on the type of interaction.

It is important to note that this feature is exclusively available for version 3.0 webhooks and is formatted in JSON. By including the interaction object in the accountUpdated webhook, SAP Customer Data Cloud provides a more granular level of data, enabling more sophisticated and contextualized responses from integrated systems. This advancement enhances your ability to manage and react to account updates, ensuring that your systems can differentiate between various types of interactions and thereby operate with greater efficiency and relevance.

This is a new feature designed to enhance the connectivity and synchronization capabilities with SAP Emarsys Customer Engagement. The Emarsys Configuration window simplifies the process of configuring connections between SAP Customer Data Cloud and Emarsys, allowing seamless export and synchronization of contact data. This integration is crucial for maintaining up-to-date and consistent user data across both platforms, ensuring that your marketing and customer engagement efforts are supported by accurate and current information.

One of the key enhancements is the ability to trigger a full resynchronization (resync) of your SAP Customer Data Cloud user base directly from the console, eliminating the need to open a support ticket. This new functionality provides greater control and flexibility, allowing administrators to manage their data with ease.

When new fields are added to the data selection, the system will not automatically update the existing accounts until they are next modified—necessitating manual intervention. Through the actions menu of the Emarsys Integration within the Emarsys Overview page, users can initiate a Resync to restart the initial load for the specified integration.

It is important to bear in mind that this process may take some time, and during this duration, other actions related to the integration will be temporarily disabled. This new capability streamlines critical maintenance tasks, ensuring your integrations operate with enhanced efficiency and reduced downtime.

You no longer need to define a field as Shared to make it available in the Emarsys connector. Instead, simply select a field in the field mapping section of the connector wizard. As a result, the shared property in the schema editor has been deprecated. This change does not affect any existing Emarsys integrations.

On the Field Selection page, you can select which fields you want to sync to a specific Emarsys tenant.

You can choose to sync all fields by selecting Customer Data Cloud Fields or select specific fields from profile, data, subscriptions, or system.

You can now select additional consent fields in the Emarsys configuration wizard, field selection step.

On the Field Selection page, you can select which fields you want to sync to a specific Emarsys tenant.

The consent statements fields are the preselected email and SMS fields and can only be changed in the Consent Mapping section.