What do we mean when we say Salesforce? What does your client mean? What does your Chief Marketing Officer (CMO) mean? What do the other architects on your team mean?

This section is focused on clarifying the terminology you’ll need to have effective conversations with all the stakeholders on projects that incorporate multiple Salesforce products.

First and foremost, Salesforce is the name of a software company. Their flagship product is the Lightning Platform, which supports many of their Salesforce branded products, like Sales Cloud and Service Cloud. In this section, we’ll clarify the difference between Salesforce the company, the Lightning Platform CRM product, and the larger Salesforce ecosystem of products that use different underlying technology.

As a B2C Solution Architect working with Packt Gear, you know that the first thing to sort out is which Salesforce Products are right for Packt Gear.

The Lightning Platform

Over time, the term Salesforce became synonymous with the CRM product, but using the name of the company to mean one specific product that a company sells can be confusing in real projects.

On top of the core Salesforce Platform, also known as Core, Force.com, or the Lightning Platform, Salesforce has built a variety of licensed products that extend the platform by adding use case specific features and functionality. The Lightning Platform is based on an extensible relational database and has robust code and declarative customization capabilities to support a variety of use cases. Many, but not all, Salesforce products are built on the Lightning Platform.

Salesforce Lightning Platform based products can be divided into two broad categories: function-specific or industry-specific. These two categories have no technical significance; they are just ways for Salesforce to organize and sell features to customers. Function-specific products provide features that are organized around a specific use case but can be used across any industry.

The function-specific Lightning Platform based products include:

• Sales Cloud
• Service Cloud
• Work.com
• Experience Cloud
• Order Management
• B2B / D2C Commerce
• Net Zero Cloud
• Loyalty Management
• Data Cloud

The industry-specific Lightning Platform based products include:

• Health Cloud
• Financial Services Cloud
• Government Cloud
• Manufacturing Cloud
• Media Cloud
• Nonprofit Cloud

Important note

The set of available Lightning Platform based products is constantly evolving so this should not be considered an authoritative list. Many of these products are not relevant to B2C solutions; we’ll be focusing on the ones that are.

The Salesforce ecosystem

Other uses of Salesforce, including Salesforce Commerce Cloud and Salesforce Marketing Cloud, refer to hybrid offerings that include products on the core Lightning Platform and products built on separate technology. They are owned by Salesforce the company, but they aren’t built on the Lightning Platform, at least not entirely.

Why does this matter? At its core, B2C Solution Architecture is about integration. When leveraging a variety of products that are all built on the Lightning Platform, there’s really no need for integration between them, since they all share a data model and can work together. When including products that aren’t built on the Lightning Platform, however, the work becomes more interesting.

As you evaluate the products needed for Packt Gear, pay attention to which of the products in the overall solution are built on the Lightning Platform and which are external and will have to be integrated.

Customer 360 evolution

As Salesforce evolved and grew from a pure CRM product company to an enterprise software vendor competing in a wide variety of industries, they needed a better way to describe the solution they offer when the entire toolset is applied. This concept became known as Customer 360.

The customer 360 concept

The heart of any successful business is its customers. Salesforce depicts this customer-centric focus with a concept called Customer 360. It’s critical for you as a B2C Solution Architect to be able to separate the marketing message from the technology solution, however.

Tip

Customer 360 is not a product, it’s a mindset. It means combining all of your Salesforce products together in service of a common understanding of your customer and their experiences with your brand.

Customer 360 component products for B2C solutions

While the term Customer 360 refers to all the Salesforce products, this book is going to focus on a few key components that are the building blocks of a B2C solution:

• Service Cloud for customer service, often abbreviated to SFSC
• B2C Commerce for direct-to-consumer selling, often abbreviated to SFCC
• Marketing Cloud Engagement for marketing and digital communications, often abbreviated to SFMC

Remember that, to design an integrated solution, we need to pay attention to which products are built on the Lightning Platform and which are not. Service Cloud is built on the Lightning Platform, whereas B2C Commerce and Marketing Cloud Engagement are not.

In addition to these three key products, the following are often used in a B2C solution and will be covered at a higher level in later chapters:

• Salesforce Order Management for order management
• MuleSoft for integration

Customer 360 and Packt Gear

Packt Gear sells products online direct to consumers, supports those consumers through customer service channels, and advertises online through a variety of digital channels including email and social media. Although there are many other operational considerations for making that happen, those are the core use cases for the initial digital transformation. So, a mix of B2C Commerce, Service Cloud, and Marketing Cloud Engagement sounds right!

We’ll cover the rest in Chapter 3, Direct-to-Consumer Selling with B2C Commerce. We’ll also evaluate integration options for pulling it all together in Chapter 8, Integration Architecture Options.

If your solution has other requirements, we’ll be outlining the overall methodology for evaluating, understanding, and incorporating products into the solution so you can apply it to whatever tools you need in your unique business environment.

B2C solution architecture focus areas

You can’t buy licenses for Customer 360 and, as much as we’d like it to be otherwise, uniting different Salesforce products under a common marketing umbrella does not make them an integrated solution. It’s the job of the solution architect to make this vision a reality by understanding a few key aspects of every Salesforce product in a solution.

A B2C solution architect is responsible for the following aspects of an integrated solution:

• Data strategy, particularly customer data, focused on where data is stored and how it moves between products in support of the overall solution.
• Integration workflows focused on when and how the various products in the solution communicate with each other (APIs, data feeds, based on events, middleware solutions, and transformations).
• Orchestration of user workflows that span between products such as unified customer login or Customer Service Representative (CSR) ordering.
• Feature and functionality mapping between products, ensuring that the best tool is used for any given job.
• Overall solution non-functional requirements such as performance, security, scalability, governance, monitoring, and total cost of ownership.
• A B2C Solution Architect is not responsible for the in-depth technical design of features and functionality specific to any single product in the overall solution.
• In the next section, we’ll cover the Salesforce Lightning Platform, the foundation of many of the products Salesforce offers. To support the B2C Solution Architect areas of responsibility outlined above, we’ll cover the platform data strategy and functionality in this chapter. In Chapter 2, Supporting Your Customers with Service Cloud, we’ll cover the integration workflows supported by the Lightning Platform.

The Lightning Platform is the core CRM technology and the original Salesforce product on which many other products are built. It is possible to purchase a license just for the Lightning Platform and implement your own custom apps on top of that platform in much the same way Salesforce has done to implement standard products like Service Cloud and Sales Cloud. In common use, when working on projects that span multiple products, the Lightning Platform based products are frequently just referred to as Core. For consistency, we’ll say Lightning Platform in this book.

The Lightning Platform uses a database behind the scenes and leverages many concepts, outlined in the following sections, that will feel familiar to anyone with a background in relational database design.

All apps built on the platform can leverage a set of capabilities, such as declarative automation, and a core data model including objects like Accounts and Contacts. Figure 1.1 shows the way products built on the Lightning Platform extend the core capabilities and data model:

Figure 1.1 – Lightning Platform and supported products

Since you’re confident Packt Gear will be leveraging Service Cloud as part of their transformation, and you know that Service Cloud is built on top of the Lightning Platform (unlike Marketing Cloud Engagement and B2C Commerce), we’ll need to review some key aspects of how the Lightning Platform operates.

Salesforce Orgs

Each independent instance of the Lightning Platform is called an Org. A Salesforce Org has a variety of licenses applied that unlock additional functionality, including product-specific licenses like Service Cloud. A Salesforce Org has a unique domain name, its own set of users, and an independent set of data.

Every Lightning Platform license includes one Production instance and a number of additional Sandbox licenses. In addition to standard Sandboxes, Salesforce has the concept of Scratch Orgs, which are ephemeral Salesforce Orgs spun up based on a JSON configuration file as part of a source-driven development workflow. They are used for a particular purpose, such as developing a feature, and then destroyed. A typical Lightning Platform DevOps workflow would leverage Sandboxes or Scratch Orgs for feature development, integration, QA, and user acceptance testing (UAT) before moving to Production.

More information on Lightning Platform editions and pricing can be found here: https://sforce.co/3w6qcx1

If you want to get your hands on a Salesforce Org so you can follow along or dig deeper into any of the concepts we’re talking about here, you can sign up for a free Developer Edition Org here: https://sforce.co/3vZ4riF

Data model

One of the foundational areas of concern for you as a Solution Architect is the design of a proper data model that spans the full solution and leverages each component product to store, expose, access, or synchronize data as appropriate. We’ll cover cross-cloud data design in more detail in Chapter 8, Integration Architecture Options, and Chapter 9, Creating a 360° View of the Customer. Since it will provide a critical piece of the overall solution, we first need to establish the key considerations for the Lightning Platform.

Objects and fields

The Lightning Platform data model resembles a traditional relational database in that data is stored in tables (called Objects) with multiple Records for a given Object, each of which includes numerous Fields.

In the image below, you can see a representation of a single Object (Account) that has multiple Fields (Account Name, Account Number, Phone, Type, and Account Owner Alias) and two Records.

Figure 1.2 – Objects, Records, and Fields

The Lightning Platform comes with several Standard Objects representing core CRM functionality including Accounts, Contacts, Leads, Opportunities, and Campaigns. These Standard Objects are pre-defined by Salesforce and they cannot be removed, but access depends on the exact licenses purchased. Many of the licensed Salesforce products that are built on the Lightning Platform also enable their own Standard Objects, such as the UserServicePresence Standard Object added by the Service Cloud product.

Each of the Salesforce-provided Standard Objects also comes with Standard Fields, which cannot be removed or modified. It is possible, however, to add additional Custom Fields to Standard Objects.

When creating a new Custom Field on any Object (Standard or Custom), a variety of data types representing numerical, Boolean, date/time, and text values are available.

Tip

The critical thing for a solution architect to understand is that all data within the Lightning Platform is stored as Records in Objects, which are like the rows in tables and have strongly typed fields that can be defined declaratively to extend the data model.

Custom Objects

Custom Objects allow the Lightning Platform to be extended, adding new data tables specific to your business needs. While the core CRM use cases are covered by the Lightning Platform, and your Service Cloud licenses will unlock additional functionality specific to customer service, every customer solution is unique, and customer-specific data will need to be added with Custom Objects.

One thing you know for sure, guided hikes are a huge aspect of the Packt Gear business. They don’t just sell gear, they sell experiences, and they need to be able to allow customers to book hikes online, promote upcoming hikes with their customers, and change their bookings through customer service.

It sounds like you’re going to need a way to track guided hikes in Salesforce! Enter Custom Objects.

You’ll work with Packt Gear to understand what the key information for a typical hike is to decide how it should be represented in the Lightning Platform.

Custom Object Name: GuidedHike__c

The following fields are found on the GuidedHike__c Custom Object:

Table 1.1 – Custom Object GuidedHike__c Fields

In the example above, we can see a new Custom Object with the API name GuidedHike__c. It has the four standard fields that are exposed for every Object, Custom or Standard: CreatedById, Name, LastModifiedById, and OwnerId plus several additional Custom Fields. Additional standard fields may be created automatically behind the scenes.

Tip

All Custom Objects and Custom Fields are suffixed with two underscores and the letter ‘c’ (__c) to indicate that they are custom.

We’ll discuss the Lookup data types in the next section, but you can also see several other data types including Date/Time, Text, Geolocation, and TextArea in use for the fields defined here.

Relationships

It’s critical to understand not just how individual Records are stored in Objects, but how those Records relate to each other.

The Lightning Platform Record relationship types are as follows:

• Lookup Relationship: A reference from one Record to a related but independent Record where each has its own security rules and owner.
• Master-Detail Relationship: A parent-child relationship where the child object (the Detail) inherits the same security rules and owner as the parent. If the parent is deleted, the child is also deleted.
• Many-to-many: A special case of Master-Detail where a junction object is created with two masters.
• External Lookup Relationship: A relationship linking a Salesforce Standard or Custom Object to an External Object, whose data is stored outside of Salesforce.

For Packt Gear, we’ve already decided that their new Guided Hike Custom Object will have a lookup relationship to the User object to reference the guide who will be conducting the hike. This type of relationship means that we’ll be able to expose the hikes that a given guide is scheduled for and look up the guide record from the hike record, but otherwise they’re separate. We can change the guide associated with the hike if someone gets sick or leaves the company. We can also create hikes with no guide planned until we decide on the right person!

One other thing Packt Gear hikes need… hikers! Packt Gear wants to be able to keep track of which of their customers have signed up for a given hike. Since each hike will have multiple hikers, and hikers can go on multiple hikes, this sounds like a many-to-many relationship!

The below Entity Relationship Diagram (ERD) represents the proposed data model:

Figure 1.3 – Entity Relationship Diagram (ERD) of GuidedHike__c Signups

The ERD above shows GuidedHike__c Objects conducted by guides, represented by the User Object, and attended by hikers, represented by the Contact Object. Since many hikers can attend a hike and a hiker can attend many different hikes, a junction Object, HikerSignup__c, is used to create a many-to-many relationship between Contact and GuidedHike__c.

Record types

The concept of a record type is important to understand as it relates to the Salesforce data model because it can impact the way that Objects are tracked and exposed within the larger solution. Creating and applying a record type to a Custom or Standard Object in Salesforce allows you to essentially describe multiple versions of the Object for different purposes.

Sticking with our Packt Gear data model, we see that the HikerSignup__c junction Object above describes Account records that are planning to attend a particular hike, represented by a GuidedHike__c record. It might at first glance seem like an odd choice to leverage Account for this purpose, since an Account record typically represents a business or organization whereas a Contact record typically represents an individual within that organization, and individuals go on hikes.

In B2C use cases, where we’re typically selling to individuals rather than to businesses, it’s common to use a special type of Account called a Person Account. The Person Account record type is applied to the Account Object and combines many of the fields typically associated with a Contact and an Account. At the database level, they’re still stored as two records, but they’re accessed and treated as one from the user’s experience.

With Salesforce, you can define any record types you need on Custom or Standard Objects. These record types control available picklist values, page layouts, and business processes associated with Records. Ultimately, however, they’re stored in the same way as other representations of the same Object, so they don’t require a separate Object definition.

The Business Account shows only fields from the Account record in Salesforce, and the Person Account shows fields from both the Account and Contact records together. A Business Account is associated with zero or more Contact records whereas a Person Account has a one-to-one relationship with a specific Contact record.

Figure 1.4 – Business Account vs. Person Account Records

Figure 1.4 shows a Business Account and associated Contact record at the top and a Person Account, which is composed of a single Account and Contact record treated as a unit.

External Objects

An External Object is a special type of Custom Object that provides an interface to data stored in external systems. They are defined much like conventional Custom Objects but rely on an External Data Source configured with Salesforce Connect. External Objects allow data from the external system to be mapped to fields defined on the Salesforce External Object. They also support the creation of page layouts and search layouts to expose external data in Salesforce. While there are some features of Custom Objects that aren’t supported on External Objects, it’s important for you as a B2C Solution Architect to understand the capability to integrate outside data sources into Salesforce in this way.

For additional reading on External Objects, see https://sforce.co/3vZtiTN.

Security

As with many of the topics in this chapter, it’s not possible to cover the Salesforce security model in its entirety in the scope of this book. Instead, we’ll cover a few key aspects that are important to understand as they impact integrated solutions.

The Salesforce security model is composed of multiple layers of security, starting with the Salesforce instance or Org, followed by an Object within that instance, then a Record of that Object, and finally, at the individual field level, within an Object.

Access to an Org, Object, or Field is controlled by a combination of a user’s Profile and Permission Sets. Permission Sets and Profiles also control what a given user can do functionally within a given Salesforce Org.

Each user has exactly one Profile assigned to them, which is associated with a particular Salesforce license and controls their default access and capabilities within Salesforce. Permission Sets allow more granular additive permissions to be applied to a subset of users within a Profile that requires additional privileges.

Access to specific Records is controlled by Org-Wide Defaults for that Object, then by the user’s Role in the hierarchy of users (if enabled), then by Sharing Rules, and finally by manual record sharing.

Figure 1.5 – Record access

As the diagram above illustrates, the Org-Wide Defaults establish the baseline access that all users have to records of a given Object. From there, Role Hierarchy, Sharing Rules, and Manual Sharing can all grant access to additional records under specific conditions.

When designing Salesforce B2C solutions that include Lightning Platform products such as Service Cloud, the details of the Salesforce security model will be handled by a platform specialist architect. Our goal here is to give you enough information to communicate effectively with the rest of your team with respect to Salesforce security.

Start learning more about Salesforce data security topics here: https://sforce.co/3wVv9ZW

For Packt Gear, you know from the above that Customer Service Representatives should have Create, Read, Update, and Delete (CRUD) access to the Hiker_Signup__c Object, since they will be helping customers sign up for hikes, but perhaps only Store Managers should be able to Create, Update, and Delete Guided_Hike__c Objects, since they are responsible for managing the planned hikes at their store.

User experience customization

A B2C Solution Architect generally won’t design the experience within any product, unless they also happen to be playing the role of Technical Architect supporting that product, but it’s important to understand the concepts to have a meaningful conversation.

Within the Lightning Platform, the key concepts to understand are Apps and Tabs.

Apps

Every Salesforce Org is composed of one-or-more apps that drive the user experience within the Org. An app is a logical grouping of tabs that support a related use case.

For example, Service is an app that includes tabs for Home, Chatter, Accounts, Contacts, Cases, Reports, Dashboards, and Knowledge.

Figure 1.6 – Apps and tabs

Figure 1.6 shows how the Lightning Platform is divided into apps, each of which has multiple tabs, which provide access to the data and functionality in the platform.

Tabs

Tabs are the primary container for a user experience within Salesforce and can represent an Object, a Lighting Page, or an external website. Lightning Page Tabs are a way of creating custom user experiences with code and are not in the scope of this book. Tabs can be shared across any number of apps.

Flow

The Lightning Platform, and by extension products like Sales Cloud, Service Cloud, and Order Management, supports a variety of declarative automation options. Declarative automation options are ways of orchestrating work that would otherwise be done manually using no-code tools.

Examples of declarative automation include automatically sending an email to a Sales Lead when an Opportunity crosses a certain value threshold, creating a Task for a Customer Service Representative (CSR) if an Order can’t be fulfilled at the requested quantity, and requiring an approval step in order to issue a discount code to a customer in excess of a given amount.

Declarative automation tools can even be more robust user experience capabilities like an interactive style quiz displayed in an Experience from Experience Cloud, allowing customers to describe their preferences. Much of the power of the Lightning Platform comes from its low-code or no-code customization capabilities and declarative automation sits at the heart of that.

The primary declarative automation tool for the Lightning Platform is Flow, so this section focuses on the capabilities of flow automation. For more information on choosing the right type of flow for a given task, see: https://sforce.co/3rFXan1

Tip

For the B2C solution architect, understanding the declarative automation capabilities of the Lightning Platform, especially Salesforce Flow, is an important part of leveraging the platform to its fullest extent. Before turning to code, always evaluate declarative capabilities first. Declarative solutions are more maintainable, easier to set up, and do not require development expertise to create and update them.

A flow can be triggered by any of the following events:

• Record created, updated, or deleted (record triggered flow)
• User experience event (e.g., button click)
• Recurring scheduled date and time (scheduled flow)
• Platform event fires
• Called from Apex
• Called from a REST API

Once triggered, a flow can support a series of steps including branching and conditional logic and any of the following activities:

• Execute Apex (custom code)
• Create a Record
• Trigger another flow
• Post to Chatter
• Execute a process
• Invoke a Quick Action
• Interact with Quip
• Send a Custom Notification
• Submit a Record for approval
• Update a Record
• Interact with the user through screens (screen flow)
• Execute complex logic
• Delete a Record
• Send an alert

Tip

At this point, you may be wondering, why don’t I just use flows for everything? The Salesforce best practice is to do exactly that. Using flows by default is more consistent and easier to maintain.

Approval Processes

The other category of declarative automation you might leverage in your solution design is an Approval Process. Approval Processes allow individual Records to be submitted to another user, often the manager of the Record owner, for approval. Since Approval Processes are rarely a critical component of multi-product solution architecture scenarios, they are mentioned here for completeness only.

You can learn more about Approval Processes here: https://sforce.co/3cojwTj

As you work through some business cases for Packt Gear, or in your own project, be sure to look for ways to leverage declarative automation tools to minimize manual work and streamline operations!

AppExchange

Salesforce AppExchange is a marketplace of ready-to-use tools created by third parties, or by Salesforce directly, that can be integrated with any Salesforce Org.

AppExchange solutions are divided into five categories:

1. Apps: Full Salesforce apps that can be added to an existing Org to support a new use case
2. Bolt Solutions: Industry-specific solutions that include broad functionality
3. Flow Solutions: Building blocks that can be added to any flow created in the Org where they’re installed
4. Lighting Data: Datasets that are exposed to your Org but maintained by a provider
5. Components: Pre-built drop-in Lightning components that can be integrated into a Salesforce user experience built on Lightning

You, as a B2C Solution Architect, should be aware of AppExchange as the primary source of buy-not-build extensions for the Lightning Platform and should evaluate potential AppExchange solutions for any use case that isn’t supported by the Lightning Platform natively or through declarative customization.

Important note

Salesforce AppExchange does not distribute extensions to Salesforce B2C Commerce, it only supports Lightning Platform based products; B2C Commerce runs on a separate technology. Some B2C Commerce extensions are listed on AppExchange for discoverability but installing them requires a developer and code changes.

Salesforce AppExchange is located at https://appexchange.salesforce.com/.

Reports and dashboards

The Lightning Platform includes support for robust reports and dashboards. Reports are summary views of data drawn from one or more Objects in Salesforce.

Reports

Reports and dashboards are a great way to gain insight into your B2C solution, but it’s important to realize that they can only summarize data that is stored on the Lightning Platform using Objects or that is represented in the Lightning Platform with an External Object.

There are the following types of Reports on the Lightning Platform:

1. Tabular reports: Simple tables of data, much like an Excel sheet
2. Summary reports: Group the source data by one or more rows
3. Matrix reports: Group the source data by one or more rows and columns
4. Joined reports: Include data from multiple reports that share a common Field

Thinking back to the guided hikes you’ve modeled for Packt Gear, a summary report would be a great way to display the hikers who have signed up for upcoming hikes!

The image below shows a sample summary report for the GuidedHike__c Object grouped by hike name:

Figure 1.7 – Summary report

Dashboards

Dashboards roll up data from multiple Reports in a visual format. Dashboards can contain up to 20 different reports and each report added to a dashboard can be represented by any of the following visual elements:

1. Horizontal or vertical bar chart
2. Horizontal or vertical stacked bar chart
3. Line chart
4. Donut chart
5. Metric (single value)
6. Gauge
7. Funnel chart
8. Scatter chart
9. Lightning table

Learn more about Reports and Dashboards here: https://sforce.co/3m93Tm9

The Salesforce ecosystem encompasses much more than just the Lightning Platform, which is why we need an overall Solution Architect in the first place! This section provides a high-level overview of the Salesforce ecosystem, including how individual products are built on specific technology platforms, and how conceptual clouds – or families of products – can span across technologies.

The image below depicts the multiple technology platforms on which a B2C solution is built.

Figure 1.8 – Platforms, products, and clouds

In Figure 1.8, the shopping cart icon identifies products that are part of Salesforce Commerce Cloud and the magnifying glass icon identifies products that are part of Salesforce Marketing Cloud. This shows how clouds (such as Commerce Cloud) can be composed of products (such as B2C Commerce and Order Management) that are built on separate platforms (such as the B2C Commerce platform and the Lightning Platform).

Your job as a B2C Solution Architect is to design solutions that incorporate and integrate products across this ecosystem, regardless of their underlying technology, to create a cohesive solution.

The Lightning Platform and beyond

As described earlier, there are many Salesforce products built on top of the Lightning Platform, but you should also understand that many are separate technologies. This is a vital difference to understand as a B2C solution architect since your job is to help your company or your clients to create an integrated experience that spans multiple products and clouds.

In the following sections, we’ll touch on products beyond the Lightning Platform and how they’ll impact a B2C solution.

Core B2C solution technologies

For a B2C solution architect, the most important non-Lightning Platform products to understand are the enterprise B2C Commerce product and the Marketing Cloud Engagement product. You may recall that the B2C Commerce product is part of Commerce Cloud, but that clouds in the Salesforce language don’t necessarily represent specific technology, they just represent logical groupings of related components. The other products in Commerce Cloud, including Order Management and B2B Commerce, are built on the Lightning Platform.

We’ll be covering B2C Commerce and Marketing Cloud in detail during Chapter 3, Direct-to-Consumer Selling with B2C Commerce, and Chapter 4, Engaging Customers with Marketing Cloud, respectively.

Since you’ll be helping Packt Gear migrate their commerce experience to Salesforce, you’ll be thinking about all these products throughout the process.

Integration-focused technologies

Beyond B2C Commerce and Marketing Cloud, it’s helpful to understand the role of Salesforce products like MuleSoft and Heroku in a B2C solution. These products serve the needs of enterprise integration scenarios and Platform-as-a-Service (PaaS) use cases. We’ll be covering these two products in more detail in Chapter 8, Integration Architecture Options.

Out-of-scope technologies

Finally, there are many other products owned by Salesforce (the company) that are not part of the Lightning Platform, such as Salesforce Anywhere, Slack, Tableau, and myTrailhead, but they are not in scope for this book since they aren’t a core part of B2C solution use cases. That certainly doesn’t mean you can’t use these products in B2C solutions – you certainly can, but they are value-added rather than being a core component.

Integrating external technology into the solution

When you’re integrating any product or technology into your overall solution the approach is the same, whether it’s another Salesforce technology, an in-house system, or a third party:

1. Review and understand the capabilities of the product and the role it will play in your overall solution; what gaps does it fill?
2. Review and understand the integration methodologies supported by the product.
3. Map your data across systems, determining what will reside in this new product and be accessed on demand from other products and what will be synchronized.
4. Orchestrate your business use cases that include this new product across other products in the solution.

The next three chapters will cover steps 1 and 2 above as they relate to Service Cloud, B2C Commerce, and Marketing Cloud, respectively. Chapter 9, Creating a 360° View of the Customer, will be focused on step 3 above across the solution and Chapter 10, Customizing for Common Business Needs, will do the same for step 4. This will give you a clear methodology you can follow for any product or technology not explicitly covered in this book when you need to incorporate it into your solution.

In the next section, we’ll cover some of the Salesforce acquisitions and legacy terminology you’ll encounter in the B2C solution space.

When working with clients or researching more about the products covered in this chapter, you may occasionally come across terminology not used in this book. While I encourage you to always use the current names of products, Salesforce is notorious for changing and redefining product names frequently and it can be hard to keep up. Sometimes, you have to meet your clients where they are and use the language they are comfortable with in order to facilitate a meaningful conversation. Always anchor back to a solid understanding of exactly what is being proposed or implemented in terms of Salesforce licensed products, the platforms they are built on, and the clouds they are a part of.

Since Salesforce is a company built largely through strategic acquisitions, many of the legacy names for products are the names of acquired companies.

Here are a few legacy product names you may encounter, for awareness:

• Demandware: The enterprise B2C Commerce product that sits outside of the Lightning Platform, often abbreviated to SFCC (though this more accurately refers to the entire Salesforce Commerce Cloud, including B2C Commerce)
• ExactTarget: The core of Marketing Cloud Engagement, including Marketing Cloud Email Studio, which also sits outside of the Lightning Platform
• CloudCraze: The original B2B Commerce product built on the Salesforce Platform, now replaced by B2B Lightning
• Community Cloud: Now called Experience Cloud, built on the Lightning Platform

Tip

It’s always best to use the most current and accurate name when possible. Language is incredibly important when describing a solution to ensure a common understanding. Once you’re moving into the solutioning phase, move away from the marketing terms and talk about what you’re building.

To recap on what we’ve learned in this chapter, Salesforce is a company, and Customer 360 is the idea of leveraging your Salesforce products in service of a common understanding of a customer. Clouds are logical groupings of one or more products that meet the needs of a particular use case or industry vertical, while Products are built on a variety of technology platforms but are always licensed, usable tools that unlock specific use cases.

The Lightning Platform, or Force.com, is the core underlying technology that supports Salesforce.com, the original CRM product from Salesforce, as well as many other Lightning Platform based products.

Equipped with this knowledge, you should be able to have a meaningful conversation about an appropriate solution that meets the needs of direct-to-consumer selling online, including marketing and support components, within the Salesforce ecosystem. You should be able to help coordinate between stakeholders and platform specialist architects, who will be handling the individual components.

In the next chapter, we’re going to cover the specific role of Service Cloud in this solution so that you’ll understand the role it plays in the larger solution.

1. Which of the following Salesforce products are built on the Lightning Platform?
   1. B2C Commerce
   2. Marketing Cloud Engagement
   3. Service Cloud
2. True or false: A Salesforce Object represents a single record in the underlying database table.
3. True or false: When looking to add a feature to B2C Commerce that isn’t supported natively, you should first evaluate solutions from AppExchange?
4. When extending the Lightning Platform data model, what is the difference between a Custom Object and an External Object?
5. You’d like to be able to query a list of the Lightning Platform account records created in the past 90 days and display them in a table. Which Lightning Platform tool would best support that need?
6. Building on the data model you’ve started for Packt Gear, you determine that the guide for a hike should receive an email alert every time a new hiker registers for their hike. What declarative automation tool should you leverage to meet this need?
7. CSRs need to go through a series of steps whenever they generate a new coupon code for a customer. Each of these steps is displayed on a different screen and each builds upon the previous. Which of the following best meets that need:
   1. Flow Builder
   2. Custom Apex Code
   3. An AppExchange solution?

There are many books dedicated to learning about the Lightning Platform in all its depth. In fact, two of the three prerequisite certifications for the B2C Solution Architect certification are focused entirely on the Lightning Platform: Platform App Developer, and Integration Architecture Designer (the third is Marketing Cloud Email Specialist).

Important note

This book does not attempt to cover any of the Lightning Platform topics in sufficient depth to take and pass the certifications. This book is focused on the topics that are essential for B2C solution architecture and builds upon that knowledge.

For additional reading on the Lightning Platform, the following Packt titles are recommended:

• Sharif Shaalan and Timothy Royer, Salesforce for Beginners, Second Edition
• Paul Goodey, Salesforce Platform App Builder Certification Guide
• Andrew Fawcett, Salesforce Platform Enterprise Architecture, Fourth Edition
• Tameem Bahri, Becoming a Salesforce Certified Technical Architect