29,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
There’s a huge demand on the market for Salesforce professionals who can create a single view of the customer across the Salesforce Customer 360 platform and leverage data into actionable insights. With Salesforce B2C Solution Architect's Handbook, you’ll gain a deeper understanding of the integration options and products that help you deliver value for organizations. While this book will help you prepare for the B2C Solution Architect exam, its true value lies in setting you up for success afterwards.
The first few chapters will help you develop a solid understanding of the capabilities of each component in the Customer 360 ecosystem, their data models, and governance.
As you progress, you'll explore the role of a B2C solution architect in planning critical requirements and implementation sequences to avoid costly reworks and unnecessary delays. You’ll learn about the available options for integrating products with the Salesforce ecosystem and demonstrate best practices for data modeling across Salesforce products and beyond.
Once you’ve mastered the core knowledge, you'll also learn about tools, techniques, and certification scenarios in preparation for the B2C Solution Architect exam.
By the end of this book, you’ll have the skills to design scalable, secure, and future-proof solutions supporting critical business demands.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 595
Veröffentlichungsjahr: 2021
Ähnliche
Salesforce B2C Solution Architect's Handbook
Design scalable and cohesive business-to-consumer experiences with Salesforce Customer 360
Mike King
BIRMINGHAM—MUMBAI
Salesforce B2C Solution Architect's Handbook
Copyright © 2021 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Group Product Manager: Alok Dhuri
Publishing Product Manager: Alok Dhuri
Senior Editor: Storm Mann
Content Development Editor: Nithya Sadanandan
Technical Editor: Karan Solanki
Copy Editor: Safis Editing
Project Coordinator: Ajesh Devavaram
Proofreader: Safis Editing
Indexer: Subalakshmi Govindhan
Production Designer: Ponraj Dhandapani
First published: October 2021
Production reference: 2110822
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-80181-703-5
www.packt.com
To my wife, Martha Bellows, for her grace and support when I decided to take on yet another project. To my parents, Michael King Sr., Linda Rivers, and Joe Rivers, who have always put their children first. None of us would be who we are without you.
– Mike King
Contributors
About the author
Mike King has worked on the most complex B2C Commerce customer implementations, including multiple brands and geographies worldwide. Mike is also a certified Salesforce instructor, teaching the B2C Technical Architect certification preparation course.
In January 2019, Mike participated in the inaugural Salesforce cross-cloud academy. He has since worked with Salesforce on the B2C Solution Architect exam development team and in real-world B2C solution architecture implementations. Mike has also presented numerous times with Salesforce on the topic of B2C solution architecture, including at TrailheaDX and Dreamforce.
When not obsessing about Salesforce, commerce, and software architecture, Mike enjoys hiking, camping, and woodworking.
This project would not have been possible without the tremendous foundation set by the Salesforce Architect Success Program, especially Abraham Lloyd. Your presentations, training materials, solution kits, and countless phone calls helped me move out of my commerce comfort zone and into the big wide world of Salesforce. My sincere thanks also to Doug Midgley, my technical reviewer and B2C Solution Architect extraordinaire, for the countless hours spent making sure this book was the best it could be.
I need to thank Slalom, especially Katie Dunlap and Shivani Majewski, who have been so supportive of this endeavor. Finally, I'd like to thank Tameem Bahri, for the encouragement and the introduction that ultimately led to this book.
About the reviewer
Doug Midgley is an Amsterdam-based cross-product Salesforce architect working for Accenture. Originally from New Zealand, he has spent nearly a decade at various locations across Europe, with 6 years of this period spent implementing Salesforce solutions in a variety of industries.
His main focus is on the various marketing products offered by Salesforce. However, he also acts as a technical architect on Salesforce core implementations.
Having worked on multiple Marketing Cloud certifications, he was also involved in the creation of the Salesforce B2C Solution Architect certification.
Outside of his work life, he is an avid balcony gardener and passionate home chef.
Table of Contents
Preface
Section : 1Customer 360 Component Products
Chapter 1: Demystifying Salesforce, Customer 360, and Digital 360
Learning the language – Salesforce, Customer 360, and Digital 360
Lightning Platform
Salesforce ecosystem
Customer 360 evolution
Digital 360
B2C solution architecture focus areas
Salesforce Platform (Force.com)
Salesforce orgs
Data model
Security
User experience customization
Automation
AppExchange
Reports and dashboards
Additional technology stacks
Salesforce Platform and beyond
Solution architecture methodology
Acquisitions and legacy terminology
Summary
Questions
Further reading
Chapter2: Supporting Your Customers with Service Cloud
Service Cloud capabilities
Service Cloud editions
Service Console
Customer support
Knowledge
Service contracts and entitlements
Computer Telephony Integration (CTI)
Omni-Channel
Service Cloud data model
Salesforce Platform data model review
Additional objects
Service Cloud APIs and integrations
Available APIs
Which API should I use?
File-based integrations
Data import and export capabilities
Outgoing requests
Service Cloud request limits and allocations
Salesforce licenses and editions
Capability capacity limitations
Total API allocations
API usage monitoring and enforcement
API access and connected apps
Feature allocation limits
Data and file storage allocations
Summary
Questions
Further reading
Chapter 3: Direct-to-Consumer Selling with Commerce Cloud B2C
B2C Commerce capabilities
Customer experience options
Roles and access
Merchant tools
Admin tools
B2C Commerce data model
Realms, instances, and sites
Designing data sharing solutions
System objects
Custom objects
Packt Gear B2C Commerce data model
B2C Commerce APIs and integrations
Feed-based integration support
Job framework
Account Manager
Open Commerce API (OCAPI)
Commerce APIs
Integration points
B2C Commerce quotas and governance
API and object quotas overview
Key solution design quotas
B2C Commerce Marketplace
Commerce Cloud product family
Order Management
Omni-Channel Inventory
B2B Commerce
Loyalty Management
Commerce Payments
Summary
Questions
Chapter 4: Engaging Customers with Marketing Cloud
The Marketing Cloud component
Content Builder
Datorama
Google Analytics 360 connector
Journey Builder
Automation Studio
Interaction Studio
Email Studio
Mobile Studio
Advertising Studio
Social Studio
Salesforce CDP
Pardot
Marketing Cloud capabilities
Email management
Journey orchestration
Cloud Pages
Programmatic customization
Marketing Cloud data model
Lists
Data Extensions
Data Designer
Business Units
Suppression
Segmentation
Marketing Cloud APIs and integrations
Feed file-based integrations
API integrations
Productized integration
Importing data into a Data Extension
Marketing Cloud SDKs
Marketing Cloud design considerations
Marketing Cloud edition constraints
Data import volumes
Putting it all together
Summary
Questions
Answers
Chapter 5: Salesforce Ecosystem – Building a Complete Solution
Experience Cloud and content management
Experience Cloud
Content Management System
OM, Payments, Loyalty Management, and B2B
Order Management
Salesforce Payments
Loyalty Management
Salesforce B2B Commerce Lightning
Enterprise CRM with Sales and CPQ and Billing
Sales Cloud
CPQ and Billing
Enterprise analytics with Tableau
Tableau integration
Tableau CRM
MuleSoft and Heroku in Customer 360
MuleSoft in Customer 360
Heroku in Customer 360
Packt Gear solution
Summary
Questions
Section 2: Architecture of Customer 360 Solutions
Chapter 6: Role of a Solution Architect
Role of a B2C solution architect
Architect team responsibilities
Stakeholders
The full team
Alignment on goals
Stakeholder interviews
Project sequencing
Building a firm foundation
Evaluating next steps
Business case breakdown
Architecture deliverables
System overview diagram
Data mapping
Sequence diagram
Technical specification documents
The Packt Gear team
Summary
Questions
Chapter 7: Integration Architecture Options
Cross-cloud application development life cycle
Service Cloud application development life cycle
B2C Commerce application development life cycle
Marketing Cloud application development life cycle
Integrated B2C solution application development life cycle
Point-to-point integrations
Prescriptive approach
Productized point-to-point integrations
B2C CRM Sync
Marketing Cloud Connect
Commerce and Marketing Connector
Integration middleware
When to explore integration middleware
Integration middleware and the point-to-point connectors
Advantages of MuleSoft
Leveraging MuleSoft in a B2C solution
Single source of truth
Incorporating a single source of truth
Leveraging Heroku
The Packt Gear approach
Summary
Questions
Further reading
Chapter 8: Creating a 360° View of the Customer
Identifying the customer
Service Cloud customer identifiers
B2C Commerce customer identifiers
Marketing Cloud customer identifiers
Cross-cloud customer identification
Mastering customer data
Evaluating business needs
Cross-cloud customer data mapping
Data privacy and consent management
Handling legacy data
360° view of the customer
Experience delivery maturity
Recognizing customers as humans
Seamless identity
The Packt Gear approach
Summary
Questions
Further reading
Chapter 9: Supporting Key Business Scenarios
Multi-cloud use case solution kits
Customer 360 Guide for Retail
Solution kits
Integrating chat bots and agent-supported chats
Supported use cases
Extending the chat solution architecture
Extending the chat workflow
Additional chat design considerations
Chat configuration extensions
Chat modifications for B2C CRM Sync
Capturing revenue with abandonment journeys
Abandoned cart workflow
Abandoned cart data model
Collect.js for abandonment scenarios
Guided hike abandonment tracking
Rebuilding the customer's cart
Summary
Questions
Chapter 10: Enterprise Integration Strategies
Multi-org, realm, and BU scenarios
Component product scopes and structures
Solution design considerations
Enterprise data management
Point-to-point integration impacts
Multi-org with Marketing Cloud Connect
Implications for B2C CRM sync
B2C Commerce and Marketing Cloud connector
Enterprise integration using middleware
Virtualizing data access at scale
Aggregating data through services
Integrations beyond Salesforce
External customer data sources
External system integration points
External integrations through middleware
Monitoring the solution
Log file aggregation
Integration middleware
Manual approaches
Custom solution
Summary
Questions
Further reading
Section 3: Salesforce-Certified B2C Solution Architect
Chapter 11: Exam Preparation Tools and Techniques
Exam structure
Credential and target audience
Topic outline and weighting
Study materials
Solution architecture guidebooks
Trailhead resources
Partner Learning Camp
Hands-on experience
Broadening your perspective
Gaining product-specific knowledge
Getting started with Salesforce
Summary
Questions
Chapter 12: Prerequisite Certifications
Marketing Cloud Email Specialist exam overview
Marketing Cloud Email Specialist topic overview
Marketing Cloud Email Specialist study materials
Platform App Builder exam overview
Platform App Builder topic overview
Platform App Builder study materials
Integration Architecture Designer exam overview
Integration Architecture Designer topic overview
Integration Architecture Designer study materials
Summary
Questions
Chapter 13: Commerce and Integration
B2C Commerce Architect exam preparation topics
The B2C Commerce Architect certification
B2C Commerce supplemental topics
Complementary component topics
Overall solution design topics
Summary
Questions
Chapter 14: Certification Scenarios
Authentication and customer identity scenarios
An example authentication and customer identity scenario
Scenario solution development
Evaluating system constraints
Customer service scenarios
Example customer service scenario
Scenario solution development
Evaluating system constraints
Marketing-focused scenarios
An example marketing scenario
Scenario solution development
Evaluating system constraints
Data integration scenarios
An example data integration scenario
Scenario solution development
Summary
Questions
Assessments
Other Books You May Enjoy
Preface
Salesforce B2C solution architecture focuses on delivering business-to-consumer experiences using Salesforce products. This capability, and the Salesforce B2C Solution Architect certification, is in high demand because it truly takes a unified viewpoint and a broad understanding to get the most out of your Salesforce investment. You need to know the capabilities of the Salesforce products at a technical level, how they integrate, what their data model is, and how they fit into a larger enterprise technology landscape.
As a B2C Solution Architect, you need business domain knowledge, as well as strong organizational and communication skills, combined with deep technical expertise in a variety of areas. Make no mistake, this is challenging to achieve, but the rewards for an organization that truly understands their customer and provides them with a seamless experience are great.
A properly designed Customer 360 solution spanning B2C Commerce Cloud, Marketing Cloud, and Service Cloud on the Salesforce Platform provides the foundation for a single view of the customer, unique insight, and transformational capabilities. Incorporating products such as Order Management, Salesforce CDP, and MuleSoft can build a richer experience, while products such as Sales Cloud, B2B Commerce, and Pardot can stretch into the B2B solution world.
Who this book is for
This book is primarily aimed at Salesforce technical audiences familiar with one or more of the products in the Customer 360 suite (especially B2C Commerce, Marketing Cloud, and Service Cloud). With this book, you'll learn more about the capabilities of the complementary products in the tool suite and expand your capabilities.
For enterprise architects looking to learn more about the Salesforce ecosystem of products or for technology leaders in B2C organizations, this book will provide a valuable reference to help cut through the noise and form a solution. Here, you will learn how these products fit into your overall enterprise technology strategy, including data and integration.
Finally, if you're evaluating Salesforce for your organization, this book will serve as a roadmap for what you'll need to achieve your goals and how it all fits together. We're focused on the architect's viewpoint; we don't get into code-level detail or administration tasks.
What this book covers
Chapter 1, Demystifying Salesforce, Customer 360, and Digital 360, explains the core terminology used in the Salesforce space, including the difference between products, clouds, and platforms, as the first step in your journey. From there, we'll provide a foundational understanding of the Salesforce Platform on which so much of the solution is built.
Chapter2, Supporting Your Customers with Service Cloud, covers Service Cloud's core functionality and goes deeper into the integration options and data model supported by the underlying Salesforce Platform.
Chapter 3, Direct-to-Consumer Selling with Commerce Cloud B2C, covers the strengths and limitations, core data model, and integration capabilities of B2C Commerce, which is the enterprise commerce engine used to power thousands of websites through the busiest shopping days of the year.
Chapter 4, Engaging Customers with Marketing Cloud, sets out how Marketing Cloud's core messaging and journeys platform supports marketing and transactional communications across a variety of channels, as well as marketing journey creation and more. We cover its capabilities, component products, data model, and integration options.
Chapter 5, Salesforce Ecosystem – Building a Complete Solution, focuses on a high-level review of additional Salesforce products, beyond the three pillars of the B2C solution architecture (B2C Commerce, Service Cloud, and Marketing Cloud), and where these products will have advantages in your solution.
Chapter 6, Role of a Solution Architect, teaches you how to assemble an appropriate team, how to structure a discovery, organize a project, and what the essential deliverables are for the B2C Solution Architect exam.
Chapter 7, Integration Architecture Options, goes into more detail about both point-to-point and middleware-based integration options. We'll also review cross-cloud development life cycles to help structure a team that can deliver on more than one workstream.
Chapter 8, Creating a 360° View of the Customer, explains how the heart of a successful B2C solution architecture is a complete and consistent picture of the customer. This means tying together commerce, marketing, service, and other experiences. We'll cover what a customer means in each system and how they all relate to one another.
Chapter 9, Supporting Key Business Scenarios, explores the Salesforce-provided solution kits that serve as a jumping-off point and then customizes and extends them for our fictional organization.
Chapter 10, Enterprise Integration Strategies, tackles topics such as multiple Salesforce orgs, B2C Commerce realms, and Marketing Cloud business units as we explore integration with other enterprise systems.
Chapter 11, Exam Preparation Tools and Techniques, serves as a quick reference for essential topics, study materials, and recommendations for how to get hands-on experience in these areas for those interested in the Salesforce B2C Solution Architect certification.
Chapter 12, Prerequisite Certifications, details how, before qualifying for the B2C Solution Architect exam, you'll need to achieve the three prerequisite certifications covered in this chapter. We'll provide a review of the topics, with an emphasis on the recommended order and which sections of this book to review for a refresher.
Chapter 13, Commerce and Integration, covers some essential topics and provides study recommendations for those interested in B2C Commerce technical architecture given that, although the Salesforce B2C Commerce Architect certification is not a prerequisite for the B2C Solution Architect certification, there are a lot of topics that will transfer across.
Chapter 14, Certification Scenarios, concludes by bringing everything together with four realistic example scenarios using our fictional Packt Enterprises company. For each scenario, we'll review possible options, shape a solution, and provide a recommended approach to help establish good habits that will transfer to the exam or real life.
To get the most out of this book
You should already have an understanding of concepts such as APIs, file exchanges, databases, and cloud software models. You should also understand high-level concepts in the business-to-consumer (B2C)domain, including customers, products, orders, marketing journeys, customer service cases, and order management. This book is a roadmap with links to a huge and ever-evolving set of Salesforce resources. You should get into the habit of using the links, bookmarking things, and reading further on your own..
While reading this book, it's helpful if you re-work the examples in a context that's meaningful to you. Think about your own organization or a client that you're working with. How is your situation similar or different? How would that impact your architectural decisions? What might you do differently and what questions would you ask to understand the situation?
This book is intended to be a roadmap to a way of thinking about architecture. It's a snapshot of the features and functionality available in a variety of software products at a point in time. That stuff will change, but the overall approach does not. Ask the right questions, figure out what tools you need and how they will work together, document your solution, and iterate.
Do not expect to use this book as a shortcut to pass the exam. There's no substitute for learning the materials and understanding how to apply them in various situations. Focus on the process, experiment, take your time, and only when you've truly locked in the information should you move on to certification.
Download the color images
We also provide a PDF file that has images of the screenshots and diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781801817035_ColorImages.pdf
Conventions used
There are a number of text conventions used throughout this book.
Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "In addition to access_token, the authentication response also supplies the REST API and SOAP API access URLs and the token expiration time, which can be used to construct additional requests and to recreate the token before it expires."
A block of code is set as follows:
<script type="text/javascript">
_etmc.push(["trackCart", {"clear_cart": true}]);
</script>
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
<script type="text/javascript">
_etmc.push(["trackCart", {"clear_cart": true}]);
</script>
Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example:
"The SFTP URL for a given Marketing Cloud instance can be found in the FTP Accounts section of Setup."
Tips or important notes
Appear like this.
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Share Your Thoughts
Once you've read Salesforce B2C Solution Architect's Handbook, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.
Learn more on Discord
To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:
http://packt.link/sfdserver
Section 1 Customer 360 Component Products
This section is about understanding the tools in your toolbox.
Before we worry about designing solutions that span products, we need to understand what products we need and how they work. We'll demystify concepts such as Customer 360 and Digital 360, clarify product and cloud boundaries, and then take each of the three primary component products in the Customer 360 ecosystem, reviewing their data models, integration options, and governance.
If you're already an expert in one of these areas, feel free to just skim through that particular chapter and focus on the areas that are newer or where you need a refresher. Everything in this book relies on understanding the capabilities of the component products covered here.
This section comprises the following chapters:
Chapter 1, Demystifying Salesforce, Customer 360, and Digital 360Chapter2, Supporting Your Customers with Service CloudChapter 3, Direct-to-Consumer Selling with Commerce Cloud B2CChapter 4, Engaging Customers with Marketing CloudChapter 5, Salesforce Ecosystem – Building a Complete SolutionChapter 1: Demystifying Salesforce, Customer 360, and Digital 360
Salesforce, Customer 360, Digital 360, Customer 360 Audiences, Commerce Cloud, Service Cloud, Marketing, CRM, CMS, OMS…starting to feel a bit lost? Getting the terminology right is the first step in designing effective solutions that leverage the Salesforce ecosystem. That means knowing the difference between products built on the Salesforce Customer Relationship Management (CRM) platform, such as Sales Cloud and Service Cloud, and products built on separate technology platforms, such as B2C Commerce and most of Marketing Cloud.
In this chapter, we'll be untangling the key terms you'll encounter in marketing materials, sales cycles, and throughout the Salesforce product documentation so you can have meaningful conversations with clients or internal stakeholders. We'll then cover some things you need to know about the Salesforce Platform, before moving on to a few other critical technologies that have been added to the Salesforce family of products. The goal here isn't to go too deep into any of these technologies – we'll be covering several in more depth in the following chapters – but to refine our language and establish a firm foundational understanding that the rest of the book will build upon.
In this chapter, we're going to cover the following main topics:
Learning the language – Salesforce, Customer 360, and Digital 360Salesforce Platform (Force.com)Additional technology stacksAcquisitions and legacy terminologyThroughout this journey, we'll be following along with Packt Gear, a fictional company that manufactures, markets, and sells outdoor supplies directly to the consumer. Packt Gear has been successful in recent years, but their home-grown technology stack is starting to hurt their ability to grow their business quickly. They've decided to transform their business by moving to Salesforce…they just need to figure out what that means. Fortunately, they have you to help!
Learning the language – Salesforce, Customer 360, and Digital 360
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 CloudService CloudWork.comEmployee CloudExperience CloudOrder ManagementB2B CommerceCustomer 360 AudiencesThe industry-specific Salesforce Platform-based products include the following:
Health CloudFinancial Services CloudGovernment CloudManufacturing CloudMedia CloudNonprofit CloudImportant 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 SFSCB2C Commerce for direct-to-consumer selling, often abbreviated to SFCC (though this more accurately refers to the entireSalesforce Commerce Cloud, including B2C Commerce as well as B2B Commerce and Order Management)Marketing Cloud for marketing and digital communication, often abbreviated to SFMCRemember 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 managementMuleSoft for integrationCustomer 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 CloudCommerce CloudExperience CloudIn 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 solutionIntegration 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) orderingFeature and functionality mapping between products, ensuring that the best tool is used for any given jobOverall solution non-functional requirements, such as performance, security, scalability, governance, monitoring, and total cost of ownershipA 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.
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, andChapter 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:
WorkflowsProcessesFlowsApproval processesWe'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 taskSending an email alertUpdating a field on the triggering record or its parentSending an outbound messageTasks 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 recordSend an email alertTrigger a flowPost to ChatterExecute a processInvoke a quick actionInteract with QuipSend a custom notificationSubmit a record for approvalUpdate the triggering record or any related recordThe 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 screensExecute complex logicDelete a recordUpdate an unrelated recordSend a non-alert emailTip
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 caseBolt solutions: Industry-specific solutions that include broad functionalityFlow solutions: Building blocks that can be added to any flow created in the org where they're installedLightning Data: Datasets that are exposed to your org but maintained by a providerComponents: Prebuilt drop in Lightning components that can be integrated into a Salesforce user experience built on LightningYou, 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 sheetSummary reports: Groups the source data by one or more rowsMatrix reports: Groups the source data by one or more rows and columnsJoined reports: Includes data from more than one report that shares a common fieldThinking 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 chartHorizontal or vertical stacked bar chartLine chartDonut chartMetric (single value)GaugeFunnel chartScatter chartLightning tableFurther reading
Learn more about reports and dashboards here: https://sforce.co/3m93Tm9.
Additional technology stacks
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:
Review and understand the capabilities of the product and the role it will play in your overall solution; what gaps does it fill?Review and understand the integration methodologies supported by the product.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.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.
Acquisitions and legacy terminology
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 PlatformCloudCraze: The original B2B Commerce product built on the Salesforce PlatformCommunity Cloud: Now called Experience Cloud, built on the Salesforce PlatformTip
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.
Summary
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.
