Salesforce Platform (Force.com)

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.