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

Field Name	Data Type	Description
CreatedById	Lookup (User)	User who created this hike record
Name	Text (80)	Name of the hike
LastModifiedById	Lookup (User)	User who last updated this hike record
OwnerId	Lookup (User, Group)	User or group who owns this record
StartTime__c	Date/Time	Date and time this hike starts
Guide__c	Lookup (User)	The tour guide
StartPoint__c	Geolocation	Location where the hike begins
Description__c	TextArea	Description of the hike

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