Salesforce Certified B2C Solution Architect Practice Test - Questions Answers, Page 6

Service Cloud is a product that allows managing customer service interactions across different channels and systems. To explain the value of Service Cloud to a retail company that currently uses B2C Commerce and Marketing Cloud, a Solution Architect can discuss the following functionalities:

Ability to allow the agent to see purchase history to support case management. Service Cloud can integrate with B2C Commerce to display customer order history and details in the service console or omnichannel routing. This allows agents to have a complete view of customer transactions and provide faster and more personalized service.

Ability to have a customer leave a journey when they have an escalated case. Service Cloud can integrate with Marketing Cloud to trigger customer journey changes based on case events. For example, if a customer has an escalated case, Service Cloud can send a signal to Marketing Cloud to pause or exit the customer from a marketing journey, and resume or re-enter the customer when the case is resolved.

Option A is incorrect because Service Cloud does not provide the ability to create a B2C storefront using Digital Experiences. Digital Experiences is a feature of Experience Cloud that allows creating branded websites and portals for customers, partners, or employees. Option B is incorrect because Service Cloud does not provide the ability to de-duplicate and create a single customer identity. This functionality can be achieved by using Customer 360 Data Manager or other data integration tools.

Reference:

https://help.salesforce.com/s/articleView?id=sf.service_overview.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.icx_b2c_order_on_behalf_of.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.mc_co_journey_builder.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.networks_overview.htm&type=5

https://www.salesforce.com/in/blog/2020/04/what-is-salesforce-customer-360.html

B2C Commerce Governance and Quotas are a set of rules and limits that apply to B2C Commerce instances to ensure the efficiency and stability of solutions built on the platform. The following considerations should be kept in mind when considering B2C Commerce Governance and Quotas:

Object quotas status is updated with an up to 20-minute delay. Therefore, a Solution Architect must consider this delay when performing calculations related to traffic and limits. Object quotas are limits on the number of objects that can be created or stored in B2C Commerce, such as products, categories, customers, orders, etc. The object quotas status shows the current usage and remaining capacity of each object quota. However, the status is not updated in real time, but with an up to 20-minute delay. This means that the Solution Architect should account for this delay when estimating the traffic and limits for each object quota.

If an enforced quota is exceeded, an exception is thrown, which prevents the current operation from completing. The Solution Architect should design the solution so that the exception can be caught within a customization. Enforced quotas are quotas that are strictly enforced by B2C Commerce and cannot be exceeded or changed by customers. Examples of enforced quotas are API calls per hour, script execution time, cache size, etc. If an enforced quota is exceeded, B2C Commerce throws an exception that stops the current operation from completing. This can result in errors or failures in the storefront or backend processes. The Solution Architect should design the solution so that the exception can be caught within a customization and handled gracefully.

Option B is incorrect because sandbox quotas cannot be softened by exporting them from a production instance and importing them onto a sandbox instance. Sandbox quotas are fixed and cannot be changed by customers. Option C is incorrect because the Solution Architect cannot assume that quota violations have not occurred unless a site is experiencing performance issues. Quota violations can occur without affecting the site performance, but they can still cause errors or failures in certain operations or processes.

Reference:

https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.dochelp/Governance/GovernanceOverview.html

https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.dochelp/Governance/ObjectQuotas.html

https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.dochelp/Governance/EnforcedQuotas.html

The B2C Commerce to Service Cloud Connector is a solution that enables integration between B2C Commerce and Service Cloud. It allows displaying customer and order information in Service Cloud, creating orders on behalf of customers, and synchronizing customer data between the two systems. When introducing the Service Cloud Connector into an existing Salesforce Org, the following functionality considerations should be aware of:

In order to implement the Service Cloud Connector it is necessary to enable Person Accounts, a change which cannot be reverted once implemented. Person Accounts are a type of account in Salesforce that combines an account and a contact into a single record. The Service Cloud Connector requires Person Accounts to store customer information from B2C Commerce. Enabling Person Accounts is an irreversible change that affects the entire Salesforce Org and may have implications for other features or customizations.

The Service Cloud Connector is distributed as a managed package that can be extended to meet client-specific needs but with core functionality that cannot be altered. A managed package is a collection of application components that can be installed from AppExchange or other sources. The Service Cloud Connector is a managed package that provides core functionality for integrating B2C Commerce and Service Cloud. The core functionality cannot be modified or deleted, but it can be extended or customized using Apex code, Visualforce pages, or Lightning components.

Option C is incorrect because the Service Cloud Connector does not natively support accounts and contacts, households, and multi-brand customer models. It only supports person accounts as a customer model by default. Option D is incorrect because the Service Cloud Connector provides a collection of Lightning components that display customer and order information within Service Cloud, which do not need to be customized or deployed by a developer.

Reference:

https://help.salesforce.com/s/articleView?id=sf.icx_b2c_overview.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.accounts_person.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.distribution_installing_packages.htm&type=5

Tokenized Sending is a feature in Marketing Cloud that allows sending messages with data that is too sensitive to store in Salesforce due to laws, regulations, or security policies. Tokenized Sending uses an API call to exchange data from an external system with Marketing Cloud at send time, without storing the data in Salesforce. Marketing Cloud Connect is a feature that enables integration between Marketing Cloud and other Salesforce clouds such as Service Cloud. When using Tokenized Sending with Marketing Cloud Connect, the following implications should be considered:

The synchronized data extensions will include the token and all PII attributes. Synchronized data extensions are tables in Marketing Cloud that store data from other Salesforce clouds using data synchronization in Marketing Cloud Connect. When using Tokenized Sending, the synchronized data extensions will include the token as well as all personally identifiable information (PII) attributes such as name, email, phone, etc. The token will serve as the subscriber key and contact key in Marketing Cloud, while the PII attributes will be used for personalization and segmentation.

The standard email address field for contacts and leads needs to be populated with a token. When using Tokenized Sending, the standard email address field for contacts and leads in other Salesforce clouds needs to be populated with a token instead of an actual email address. The token resembles a standard email address but contains encrypted information about the subscriber. The token is used to exchange data with the external system at send time and send messages to the actual email address.

Option B is incorrect because not all emails need to be sent through Marketing Cloud or Marketing Cloud Connect to avoid disruptions when using Tokenized Sending. However, it is recommended to do so to ensure consistent tracking and deliverability data across clouds. Option D is incorrect because the token with all supporting attributes does not need to be stored in Service Cloud when using Tokenized Sending. The token and the attributes are stored in the external system and only exchanged with Marketing Cloud at send time.

Reference:

https://help.salesforce.com/s/articleView?id=sf.mc_overview_tokenized_sending1.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.mc_co_tokenized_sending.htm&type=0

Marketing Cloud account hierarchy is the way of organizing Marketing Cloud accounts and business units to support different business needs and use cases. A Marketing Cloud tenant is a top-level account that contains one or more business units. A business unit is a sub-account that can have its own data, content, users, and permissions. To set up Marketing Cloud account hierarchy for a company that has ecommerce sites for three countries: Australia, New Zealand, and Singapore, a Solution Architect should recommend the following:

Use a single Marketing Cloud tenant and map business units to each site irrespective of the realm. This option allows the company to have a centralized account that can manage all the sites across different countries and regions. It also allows the company to have separate business units for each site that can have their own data, content, users, and permissions. This way, the company can maintain consistency and compliance across all the sites, while also enabling personalization and segmentation for each site.

Option A is incorrect because using a separate Marketing Cloud tenant for each site is not necessary or advisable. It would create complexity and inefficiency in managing multiple accounts and duplicating data and content across them. It would also increase the cost and maintenance of the solution. Option B is incorrect because using a separate Marketing Cloud tenant for each realm and mapping business units to sites within each realm is not optimal or scalable. It would create inconsistency and fragmentation between the realms and limit the ability to share data and content across them. It would also increase the cost and maintenance of the solution. Option D is incorrect because using a single Marketing Cloud tenant and mapping business units to each realm is not sufficient or flexible. It would not allow the company to have separate data, content, users, and permissions for each site within a realm. It would also limit the ability to personalize and segment for each site.

Reference:

https://help.salesforce.com/s/articleView?id=sf.mc_overview_account_hierarchy.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.mc_overview_business_units.htm&type=5

Salesforce Shield Encryption is a feature that allows encrypting sensitive data at rest in Salesforce without compromising functionality or performance. Shield Encryption uses probabilistic encryption to protect data while preserving its format and length. Field-Level Encryption is a feature in Marketing Cloud that allows encrypting sensitive data at rest in Marketing Cloud using customer-managed keys. Field-Level Encryption uses deterministic encryption to protect data while preserving its format and length. When determining an appropriate solution for encrypting specific fields in Service Cloud as well as in data extensions in Marketing Cloud, the following considerations are relevant:

With Shield, encrypted fields cannot be used to filter or sort in Process Builder and Flow Builder. Process Builder and Flow Builder are tools in Salesforce that allow creating automated workflows and processes based on certain criteria or conditions. However, Shield Encryption does not support filtering or sorting on encrypted fields in these tools, because probabilistic encryption does not allow exact matching or comparison of values.

Shield encryption can be done on any standard or custom field on all field types, but cannot be set to encrypt those fields in Marketing Cloud. Shield Encryption supports encrypting any standard or custom field on any field type in Salesforce, such as text, email, phone, date, etc. However, Shield Encryption does not apply to Marketing Cloud fields or data extensions, because they are stored in a separate database from Salesforce. To encrypt fields in Marketing Cloud, Field-Level Encryption must be used.

Option A is incorrect because with Shield, encrypted fields are visible to the user if they have the View Encrypted Data permission, but there are other feature impacts such as filtering, sorting, searching, etc. Option C is incorrect because Field-Level Encryption is not required on Marketing Cloud to encrypt the custom fields if they are already encrypted by Shield Encryption in Service Cloud. However, Field-Level Encryption can be used on Marketing Cloud if additional encryption or customer-managed keys are needed.

Reference:

https://help.salesforce.com/s/articleView?id=sf.security_pe_overview.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.security_pe_considerations_general.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.mc_overview_field_level_encryption.htm&type=5

A self-service portal is a feature in Service Cloud that allows creating branded websites and portals for customers to access self-service resources, such as knowledge articles, case management, chat, etc. To ensure that the theme of the self-service portal is consistent with the theme of the B2C Commerce storefront, a Solution Architect should do the following:

Set the value of the Style Sheet URL setting to match the publicly-accessible URL of the style sheet the organization wants to use. The Style Sheet URL setting is a configuration option in Service Cloud that allows specifying a custom style sheet for the self-service portal. The style sheet must be hosted on a publicly-accessible web server and must follow certain guidelines and limitations. By setting the value of the Style Sheet URL setting to match the style sheet used by the B2C Commerce storefront, the Solution Architect can ensure that the self-service portal has the same look and feel as the storefront.

Option B is incorrect because there is no Portal Theme URL setting in Service Cloud. Option C is incorrect because copying any relevant CSS code from the organization's website and pasting it into the pages for the self-service portal in Page Builder is not a recommended or supported way of customizing the theme of the self-service portal. Option D is incorrect because making a copy of the appropriate CSS file from the organization's web server and uploading it to the self-service portal is not possible or advisable. The CSS file must be hosted on a publicly-accessible web server and referenced by the Style Sheet URL setting.

Reference:

https://help.salesforce.com/s/articleView?id=sf.networks_overview.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.selfservice_style_sheet.htm&type=5

Salesforce Connect is a feature that allows accessing and integrating external data from various sources without copying or storing it in Salesforce. Salesforce Connect uses external objects and external data sources to create a virtual data model that can be used in Salesforce applications and tools. The justifications for using Salesforce Connect in this solution are:

Need access to all external data in near real-time. Salesforce Connect allows accessing external data from ERP or other systems in near real-time, without any delays or synchronization issues. This ensures that the data is always up-to-date and consistent across systems.

The external data is changing frequently. Salesforce Connect allows reflecting any changes or updates made to the external data in ERP or other systems immediately in Salesforce, without requiring any manual intervention or batch processes. This ensures that the data is always accurate and reliable across systems.

Need real-time access to a small fraction of external data. Salesforce Connect allows accessing only a small fraction of external data that is relevant and needed for a specific use case, such as displaying customer order history or details. This reduces network overhead and improves performance.

Option A is incorrect because accessing external data using workflows and triggers is not possible or supported with Salesforce Connect. Option C is incorrect because integrating external data without writing custom code is not a justification for using Salesforce Connect, as it may require some custom code or configuration depending on the data source and use case.

Reference:

https://help.salesforce.com/s/articleView?id=sf.datacloud_connect_overview.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.datacloud_connect_considerations.htm&type=5

The B2C Commerce - Service Cloud Connector is a solution that enables integration between B2C Commerce and Service Cloud. It allows displaying customer and order information in Service Cloud, creating orders on behalf of customers, and synchronizing customer data between the two systems. Prior to implementation, a Solution Architect should keep in mind the following considerations:

Guests or anonymous storefront shoppers are not supported in this scenario. The Service Cloud Connector requires a customer account to be created in B2C Commerce and Service Cloud for each shopper. Guests or anonymous shoppers who do not have an account cannot be supported by the Service Cloud Connector. Therefore, the Solution Architect should ensure that the B2C Commerce storefront requires or encourages shoppers to create an account before placing an order.

Service agents need a corresponding storefront login mapped to their Service Cloud user record. The Service Cloud Connector requires a mapping between the service agent's user record in Service Cloud and the customer's account record in B2C Commerce. This mapping allows the service agent to access customer and order information from B2C Commerce and create orders on behalf of the customer using the storefront login. Therefore, the Solution Architect should ensure that the service agent's user record has a field that stores the corresponding storefront login of the customer.

The Service Cloud Connector only supports Person Accounts as a customer model. Person Accounts are a type of account in Salesforce that combines an account and a contact into a single record. The Service Cloud Connector requires Person Accounts to store customer information from B2C Commerce. Therefore, the Solution Architect should ensure that Person Accounts are enabled and configured in Service Cloud before implementing the Service Cloud Connector.

Option B is incorrect because B2C Commerce does not need to be registered as a remote site for the Service Cloud Connector to work. A remote site is a web service or domain that Salesforce can access from Apex code or Visualforce pages. The Service Cloud Connector does not use Apex code or Visualforce pages to access B2C Commerce, but rather uses REST APIs and OAuth 2.0 authentication.

Reference:

https://help.salesforce.com/s/articleView?id=sf.icx_b2c_overview.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.accounts_person.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.remoteaccess_define.htm&type=5