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 in order 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, such as 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.

Lightning Platform

Over time, the term Salesforce has become synonymous with the CRM product, but using the name of the company to mean one specific product that the 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-based CRM product sold by Salesforce is referred to as Salesforce.com (as opposed to just Salesforce, which indicates the company). Many, but not all, Salesforce products are built on the Salesforce Platform.

Salesforce 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 Salesforce Platform-based products include the following:

• Sales Cloud
• Service Cloud
• Work.com
• Employee Cloud
• Experience Cloud
• Order Management
• B2B Commerce
• Customer 360 Audiences

The industry-specific Salesforce Platform-based products include the following:

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

  Important note

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

Salesforce ecosystem

Other uses of Salesforce, including Salesforce Commerce Cloud and Salesforce Marketing Cloud, refer to hybrid offerings that include products on the core Salesforce Platform and products built on separate technology. They are owned by Salesforce the company, but they aren't built on the Salesforce 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 Salesforce Platform, there's really no need for integration between them; they all share a data model and can work together. When including products that aren't built on the Salesforce Platform, however, the work becomes more complicated.

As you evaluate the products needed for Packt Gear, pay attention to which of the products in the overall solution are built on the Salesforce 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 bring when the entire toolset is applied. This concept became known as Customer 360.

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 to a common understanding of your customers 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 (though this more accurately refers to the entire Salesforce Commerce Cloud, including B2C Commerce as well as B2B Commerce and Order Management)
• Marketing Cloud for marketing and digital communication, often abbreviated to SFMC

Remember that we need to pay attention to which products are built on the Salesforce Platform and which are not. Service Cloud is built on the Salesforce Platform, whereas B2C Commerce and most of the components of Marketing Cloud 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 directly to the consumer, supports these consumers through customer service channels, and advertises online through a variety of digital channels, including email and social. 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 sounds right! Remember that B2C Commerce is only one product in the Salesforce Commerce Cloud family of products.

We'll cover the rest in Chapter 3, Direct-to-Consumer Selling with Commerce Cloud B2C. We'll also evaluate integration options for pulling it all together in Chapter 7, 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.

If Customer 360 means using the full power of Salesforce in service to your customer-centric vision, Digital 360 is focused on the customer experience portion of the solution.

Digital 360

The term Digital 360 was coined in September 2020 to refer specifically to the following products within the Customer 360 ecosystem:

• Marketing Cloud
• Commerce Cloud
• Experience Cloud

In other words, these are the three products that are most likely to interface directly with the end customer rather than being tools you use to run your business.

As a rule, it's better to minimize the use of marketing terms such as Digital 360 since they really don't tell us much about the solution being discussed. Saying Digital 360 isn't as clear as saying Marketing Cloud, Commerce Cloud, and Experience Cloud and it's subject to change over time.

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 these 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:

• The 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, event-based, 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.

The Salesforce 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 Salesforce Platform and implement your own custom apps on top of that platform in much the same way Salesforce has done to implement standard products such as Service Cloud and Sales Cloud. In common use, when working on projects that span multiple products, Salesforce Platform-based products are frequently just referred to as Core. For consistency, we'll say Salesforce Platform in this book.

The Salesforce 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 such as Accounts and Contacts. Figure 1.1 shows the way products built on the Salesforce Platform extend the core capabilities and data model:

Figure 1.1 – Salesforce 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 Salesforce Platform (unlike Marketing Cloud and B2C Commerce), we'll need to review some key aspects of how the Salesforce Platform operates.

Salesforce orgs

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

Every Salesforce Platform license includes one production instance and some 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 Salesforce Platform DevOps would leverage sandboxes or scratch orgs for feature development, integration, QA, and User Acceptance Testing (UAT) before moving to production.

Further reading

More information on Salesforce 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 key 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 7, Integration Architecture Options, and Chapter 8, Creating a 3600 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 Salesforce Platform.

Objects and fields

The Salesforce 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 following figure, 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 Salesforce Platform comes with several standard objects representing core CRM functionality, including Accounts, Contacts, Leads, Opportunities, and Campaigns. These standard objects are predefined 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 Salesforce 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 Salesforce 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 Salesforce Platform to be extended by adding new data tables specific to your business needs. While the Core CRM use cases are covered by the Salesforce Platform, and your Service Cloud licenses will unlock additional customer service-specific functionality, 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 Salesforce Platform.

Custom object name: GuidedHike__c

The following fields are found on the GuidedHike__c custom object:

Table 1.1 – GuidedHike__c custom object fields

In the preceding example, we can see a new custom object with the GuidedHike__c API name. 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 also how those records relate to each other.

The Salesforce 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 relationship: 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 following Entity Relationship Diagram (ERD) represents the proposed data model:

Figure 1.3 – ERD of GuidedHike__c signups

The previous ERD 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 HikerSignup__c junction object 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 preceding HikerSignup__c junction object describes Account records who 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. A Person Account is a record type applied to the Account object that combines many of the fields typically associated with Contact and Account. At the database level, they're still stored as two records, but they're accessed and treated like one from a user experience viewpoint.

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.

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

Figure 1.4 – Business Account versus 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 the 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.

Further reading

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 is able to 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 preceding diagram illustrates, 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 Salesforce 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.

Further reading

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

For Packt Gear, you know from the preceding information that CSRs should have Create, Read, Update, and Delete (CRUD) access to the Hiker_Signup__c object, since they will be helping customers to 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 be designing 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 in order to have a meaningful conversation.

Within the Salesforce 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 Salesforce 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 Lightning page, or an outside website. Lightning Page tabs are a way of creating custom user experiences with code and are not in scope for this book. Tabs can be shared across any number of apps.

Automation

The Salesforce Platform, and, by extension, products such as 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 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 such as an interactive-style quiz displayed in an experience from Experience Cloud, allowing customers to describe their preferences. Much of the power of the Salesforce Platform comes from its low-code or no-code customization capabilities and declarative automation sits at the heart of that.

We'll give a high-level overview of the four declarative automation tools supported by Salesforce.

Further reading

For more information on choosing the right automation tool for a given task, see https://sforce.co/3d6CnBw.

Tip

For the B2C solution architect, understanding the declarative automation capabilities of the Salesforce Platform, especially flows, is an important part of leveraging the platform to its fullest extent. Before turning to code, always evaluate declarative capabilities first.

The four declarative automation tools available in the Salesforce Platform are as follows:

• Workflows
• Processes
• Flows
• Approval processes

We'll cover each of these four automation tools in the following sections.

When evaluating which tool to use, it's important to use the simplest tool that is capable of doing what you need. In the following sections, we'll review the capabilities and limitations of each declarative automation tool.

Because processes and flows are both parts of Lightning flows, we'll treat them together.

Workflows

Workflows are the most basic of the four declarative automation tools supported by the Salesforce Platform.

Workflow rules are only capable of four possible actions:

• Creating a task
• Sending an email alert
• Updating a field on the triggering record or its parent
• Sending an outbound message

Tasks are a type of object in the Salesforce Platform that track to-do items assigned to individual users. They're an appropriate way to queue up a manual action that needs to be taken in response to a record change. Email alerts leverage the Salesforce Platform-native email templates; they cannot be customized to use an outside email service such as Salesforce Marketing Cloud. Outbound messages are a Salesforce Platform capability that allows XML-based messages to be sent to a designated endpoint.

Tip

The only thing you can do with a workflow that you can't also do with a process or flow is send an outbound message.

Lightning flow

Lightning flow is an umbrella term for Salesforce automation that includes two of the four total declarative automation options: Process Builder-created processes and Flow Builder-created flows.

Processes and flows share the same underlying implementation and many of the same capabilities, but there are a few key differences that are important to understand when deciding which to leverage for a particular solution.

Process Builder-created processes

Processes, which are implemented with Process Builder, are more capable than workflows (except for the ability to send outbound messages), but simpler than flows. Processes consist of a series of simple If / Then / Else statements evaluated in order when a triggering event occurs. When the condition is satisfied, an action is taken, and the process either concludes or continues to evaluate the next condition (depending on the configuration).

Processes are triggered whenever a record is created or updated for the associated object, when explicitly called from another process, or when a platform event is received.

A process can do any of the following as a result of a triggering event:

• Execute Apex (custom code)
• Create a record
• Send an email alert
• Trigger a flow
• Post to Chatter
• Execute a process
• Invoke a quick action
• Interact with Quip
• Send a custom notification
• Submit a record for approval
• Update the triggering record or any related record

The only thing a process can do that a flow cannot is execute another process.

Processes do not have the capability to execute complex logical branching or loops or to interact directly with the user. For that, we need to leverage flows.

Flow Builder-created flows

Flows, which are implemented with Flow Builder, are the most robust automation tool available in the Salesforce Platform toolkit.

They can do all the things a process can do plus the following:

• Interact with the user through screens
• Execute complex logic
• Delete a record
• Update an unrelated record
• Send a non-alert email

  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 final category of declarative automation capabilities is an approval process. Approval processes allow individual records to be submitted to another user, often the manager of the record owner, for approval. Approval processes support all the same actions that workflows do as listed previously. Since approval processes are rarely a critical component of multi-product solution architecture scenarios, they are mentioned here for completeness only.

Further reading

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:

• Apps: Full Salesforce apps that can be added to an existing org to support a new use case
• Bolt solutions: Industry-specific solutions that include broad functionality
• Flow solutions: Building blocks that can be added to any flow created in the org where they're installed
• Lightning Data: Datasets that are exposed to your org but maintained by a provider
• Components: Prebuilt 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 Salesforce Platform and should evaluate potential AppExchange solutions for any use case that isn't supported by the Salesforce Platform natively or through declarative customization.

Important note

Salesforce AppExchange does not distribute extensions to Salesforce B2C Commerce; it only supports Salesforce 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 Salesforce 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 in the Salesforce Platform using objects or that is represented in the Salesforce Platform with an external object.

There are four types of reports in the Salesforce Platform:

• Tabular reports: Simple table of data, much like an Excel sheet
• Summary reports: Groups the source data by one or more rows
• Matrix reports: Groups the source data by one or more rows and columns
• Joined reports: Includes data from more than one report that shares 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 following screenshot 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:

• Horizontal or vertical bar chart
• Horizontal or vertical stacked bar chart
• Line chart
• Donut chart
• Metric (single value)
• Gauge
• Funnel chart
• Scatter chart
• Lightning table

  Further reading

  Learn more about reports and dashboards here: https://sforce.co/3m93Tm9.

The Salesforce ecosystem encompasses much more than just the Salesforce 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 following figure 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 Salesforce 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.

Salesforce Platform and beyond

As described earlier, there are many Salesforce products built on top of the Salesforce 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 Salesforce Platform and how they'll impact a B2C solution.

Core B2C solution technologies

For a B2C solution architect, the most important non-Salesforce Platform products to understand are the enterprise B2C Commerce product and the Marketing Cloud 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 Salesforce Platform.

We'll be covering B2C Commerce and Marketing Cloud in detail during Chapter 3, Direct-to-Consumer Selling with Commerce Cloud B2C, 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 across all of these products throughout the process.

Integration-focused technologies

Beyond B2C Commerce and Marketing Cloud, it's helpful to understand the role of Salesforce products such as 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 during Chapter 7, Integration Architecture Options.

Out-of-scope technologies

Finally, there are many other products owned by Salesforce (the company) that are not part of the Salesforce Platform, such as Salesforce Anywhere, Slack, Tableau, and myTrailhead, but are not in the scope of 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.

Solution architecture methodology

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 as they relate to Service Cloud, B2C Commerce, and Marketing Cloud, respectively. Chapter 8, Creating a 360° View of the Customer, will be focused on step 3 across the solution, and Chapter 9, Supporting Key Business Scenarios, 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 Salesforce 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, including Marketing Cloud Email Studio, which also sits outside of the Salesforce Platform
• CloudCraze: The original B2B Commerce product built on the Salesforce Platform
• Community Cloud: Now called Experience Cloud, built on the Salesforce 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 solution 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 to a common understanding of a customer. Furthermore, 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 and usable tools that unlock specific use cases.

The Salesforce Platform, or Force.com, is the core underlying technology that supports Salesforce.com, the original CRM product from Salesforce, as well as many other Salesforce Platform-based products. Digital 360 is a marketing term that represents Marketing Cloud, Commerce Cloud, and Experience Cloud used together in a solution.

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 Salesforce Platform: B2C Commerce, Marketing Cloud, or 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 the AppExchange.
4. When extending the Salesforce 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 Salesforce Platform account records created in the past 90 days and display them in a table. Which Salesforce 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's the simplest declarative automation tool that will 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: Process Builder, Flow Builder, custom Apex code, or an AppExchange solution?
8. When reviewing some promotional materials at a trade show, you find some interesting capabilities attributed to Digital 360 – which Salesforce products is this referring to?

There are many books dedicated to learning about the Salesforce Platform in all its depth. In fact, two of the three prerequisite certifications for the B2C solution architect certification are focused entirely on the Salesforce 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 Salesforce Platform topics in sufficient depth to take and pass the prerequisite certifications. This book is focused on the topics that are essential for B2C Solution Architecture and builds upon that prerequisite knowledge.

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

• Sharif Shaalan, Salesforce for Beginners
• Paul Goodey, Salesforce Platform App Builder Certification Guide
• Andrew Fawcett, Force.com Enterprise Architecture
• Tameem Bahri, Becoming a Salesforce Certified Technical Architect