4
Salesforce Data Management
With a grasp of Master Data Management (MDM) concepts under our belt, we can now look at Salesforce Data Management. In this chapter, we'll look at how the Salesforce data model and Salesforce licensing work together. The license types chosen for a solution have an impact on the objects available. This can extend to record sharing facilities available in the case of Experience Cloud license types.
We'll look at what data persistence looks like on the Salesforce Platform and how that works when governing solutions on the Salesforce Platform.
Next, we'll expand on our golden record theory from Chapter 3, Master Data Management, to explain what a Single Customer View (SCV) looks like on the Salesforce Platform, and how data from multiple Salesforce clouds and multiple Salesforce instances can be pieced together.
Therefore, in this chapter, we'll cover the following topics:
- Analyzing Salesforce license types and access to objects
- Persisting data
- Representing a single view of the customer on the Salesforce Platform
- Pulling together data from multiple Salesforce instances
Analyzing Salesforce license types and access to objects
In this section, we're going to cover how the different Salesforce licensing options affect the objects and standard functionality available to users. Given the vast array of functionality available in Salesforce products, it is important to ascertain what the required objects and functionality will be (from both an internal and external access perspective) so that the correct licenses can be purchased. As expected, certain licenses are more expensive than others—for example, Service Cloud licenses are more expensive than Sales Cloud. In the case of Experience Cloud, this type of license not only affects the objects available for users but can affect sharing rules and role hierarchy too. We'll get to those implications further along in this section.
Because of the cruciality of getting licensing correct, an important artifact produced during the Certified Technical Architect (CTA) review board is Actors and Licenses. This is essentially a listing of different user types and the licenses those different user types (also known as personas) need to interact correctly with the proposed solution. As a Salesforce architect, you should therefore consider this exercise as a pillar to your solution. If it is wrong, it can have profound impacts on the way users work.
Important note
Experience Cloud = Community Cloud: Salesforce has rebranded Community Cloud to become Experience Cloud. This is intentional and represents a shift from Communities being a lens into your Salesforce data for external users. The technology that powers Community Cloud/Experience Cloud has evolved so much that entire digital experiences and commerce storefronts can be powered from it, hence the rebranding. For the avoidance of doubt, Community Cloud, Communities, and Experience Cloud are one and the same. The Salesforce documentation isn't fully updated at the time of writing, so be mindful that you may still see references to Community Cloud and Communities from time to time.
Let's now delve deeper into the different types of licensing on the Salesforce Platform.
Standard platform licensing
The core Salesforce Platform consists of several products, as follows:
- Lightning Platform
- Sales Cloud
- Service Cloud
- Experience Cloud
These products are all built around the core application framework and relational database that underpins the Salesforce Platform. In fact, Sales Cloud, Service Cloud, and Experience Cloud can all be thought of as enhancements to the core Lightning Platform. For example, Sales Cloud has (among others) the Account, Contact, Opportunity, and Lead objects. These are predefined and interrelated objects that allow for a sales process to be quickly and easily set up and facilitated. They can also be thought of as a predefined set of objects and associated functionality that build upon the foundations of the Lightning Platform—namely, a relational database and application tier.
Service Cloud builds upon the functionality available in Sales Cloud (although Service Cloud and Sales Cloud are designed to address different use cases). Service Cloud attracts a different cost model than Sales Cloud, given the difference in exposed functionality to users, and subsequently is classed as a different product license.
Experience Cloud can be thought of as a lens into your Salesforce data, and several Experience Cloud license types are available. These are explained in the following section. Experience Cloud only exposes access to objects on the core platform, so that includes Sales Cloud objects, Service Cloud objects (if licensed), and Custom objects.
When designing solutions that require data to reside on the Salesforce Platform, consider the Standard platform licenses that will be required for your internal users. Generally, if a standard object offered by Sales or Service Cloud is designed to hold a specific type of data or is used to perform a certain function, then it is advisable to take advantage of it for the functionality built around it.
For example, use Sales Cloud when you require prospecting functionality because this is offered by the out-of-the-box Lead object. There are also features such as Lead Assignment Rules and conversion to create an Account, Contact, and Opportunity record. It would be ineffective to reinvent the wheel to create these objects yourself. Similarly, when you have requirements for Service-Level Agreement (SLA) functionality for your customers cases, Service Cloud offers the Entitlement and Milestone objects for this purpose. If you wish to provide access to your customers so that they can raise support queries or have issues with the products you've sold them, Experience Cloud provides the means to do this.
Now that we've covered Standard platform licensing for your internal users, let's look at Experience Cloud licensing for external user access.
Experience Cloud licensing
Experience Cloud is the way external users (those not internal to your company) access Salesforce. In this section, we're going to look at the license types available for your external users.
Experience Cloud licensing works differently from Standard platform licensing in that each license type affects access to objects and record sharing differently. There are different types of Experience Cloud licenses to use when designing solutions—namely, these ones:
- External Apps. Used for custom digital experiences, including customer engagement and brand loyalty. Limited access to Salesforce objects. This license type can be used with Person Accounts.
- Customer Community. Used for Business-to-Consumer (B2C) experiences with large numbers of users that need access to the Case object or Salesforce Knowledge. This license type can be used with Person Accounts.
- Customer Community Plus. Used for B2C experiences where users need access to reports and dashboards and need advanced sharing. This license type can be used with Person Accounts.
- Partner Community. Business-to-business (B2B) experiences where users need access to Partner Relationship Management (PRM) objects such as Lead and Opportunity. This license type cannot be used with Person Accounts.
- Channel Account. B2B sites that calculate their usage based on the number of partners instead of the number of individual users.
At the time of writing, the exam covered the Customer Community, Customer Community Plus, and Partner Community license types. Therefore, those license types will be the focus of the next section.
Experience Cloud licensing and sharing
The license type used with Experience Cloud can have an impact on sharing and the way record access works for users. In a nutshell, the Customer Community license type doesn't support roles, and sharing sets are used instead of sharing rules. Sharing sets are used to grant record access to any record associated with an account or contact that matches the users account or contact record. Sharing sets can also grant record access using access mapping. Access mappings work by using indirect lookups from the user or target record to an account or contact record. An example of this (as explained at https://help.salesforce.com/s/articleView?id=sf.networks_setting_light_users.htm&type=5) is granting a Customer Community license user access to all cases related to an account, that is also the account related to the contact that is associated with the users contact record.
In addition to sharing sets, the Customer Community Plus and Partner Community license types allow for the use of owner-based or criteria-based sharing rules in order to share records with Experience Cloud users. Also, Experience Cloud users with either of these license types support external roles (three levels maximum). Think of this as a mini role hierarchy. These roles can then be subordinate roles of an internal role in the role hierarchy. Record access can therefore be opened up to external users through the external roles, and these in turn can be opened up to internal users.
The other main difference between the Customer Community Plus and Partner Community license types is the object access and also how reports and dashboards can be interacted with.
This is explained in the following diagram:
Figure 4.1 – Experience Cloud License type differences
Important note
When to use the different Experience Cloud license types: In short, there is a relatively simple way to determine which license type to use for Experience Cloud sites.
Generally, start with the Customer Community license type, and then adapt this according to your requirements, as follows:
If advanced sharing (beyond sharing sets) read-only access to reports and dashboards is required, move to Customer Community Plus licenses.
If Lead or Opportunity object access is required, or the ability to create reports and dashboards is required, choose Partner Community.
Of course, there are additional nuances (explained at https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.users_license_types_communities.htm), but this should be a good way to get started when learning for the exam.
Licensing for Salesforce products not on the core platform
The non-core products in the Salesforce suite (such as Commerce Cloud and Marketing Cloud) are licensed differently. Their licensing is not in the scope of the exam, and therefore won't be covered in this book.
Full products versus Salesforce-managed packages
Salesforce products on the core platform—such as Sales Cloud, Service Cloud, and Experience Cloud—are licensed on a per-user, per-month basis. Each license opens up more functionality and access to different entities on the Salesforce core platform.
Certain products in the Salesforce suite are licensed separately and interact with the core platform through the use of connectors, as is the case with Marketing Cloud, Pardot, or Commerce Cloud. The exam syllabus covers core platform usage, and therefore revision should concentrate on the data entities and functionality afforded by the core platform products only.
Salesforce-managed packages that are built for the core platform, including (but not limited to) Financial Services Cloud, Manufacturing Cloud, and Health Cloud, are essentially licensed managed packages that install additional entities, apps, and other functionality (such as flows) onto the core platform.
Let's now look at package licensing, which also applies to managed and AppExchange packages.
AppExchange and package licensing
Depending on the licensing requirements of an AppExchange, managed, or unmanaged package, permission set licenses are the typical method of licensing paid packages. As you'll already know, when installing a package from AppExchange (or directly from Salesforce, in the case of an offering such as Financial Services Cloud), users will need to be given the correct permission set licenses in order to gain access to any objects or other functionality specific to that package. When designing solutions that require access to data entities and other functionality exposed by a package, one or more permission set licenses associated with that managed package will need to be given to the users that require access to that functionality.
As you now know, there are myriad licensing options available to us as Salesforce architects when it comes to producing robust, scalable solutions on the platform to deliver the right functionality to the right users. This extends to external users of the system interacting in a controlled manner to the data held within your Salesforce Organization (org). We can now turn to persisting data in a consistent manner on the Salesforce Platform.
Persisting data
Ensuring data is persisted in a consistent manner is paramount to the long-term success of a Salesforce implementation. Therefore, it is important to understand the causes of data quality issues and the techniques available to improve data quality but ideally prevent it from happening in the first place as much as possible.
Data quality issues can arise due to the age of the data, how complete and accurate the data is, whether duplicate data exists, and the consistency in the way data is used. Data quality issues can cause users to be presented with incomplete or incorrect information, causing them to spend more time gathering that information (which may require them to spend time in multiple systems or with multiple data sources). Worse still, customers may be subjected to poor customer service caused by account managers or service agents having incomplete or incorrect information. Lastly, frustrated users may be deterred from utilizing a System Of Record (SOR) and move to offline processes instead, meaning reduced or degrading system adoption. Luckily, Salesforce has several features that can be utilized in order to address these potential issues.
Starting with duplication of data, Salesforce has the ability to specify matching and duplicate rules in order to identify and merge records of a particular type, such as duplicate leads (such as an example of multiple Web2Lead captures from the same person yet existing as multiple lead records). The out-of-the-box matching and duplicate rules are built around sensible defaults, such as leads or contacts sharing an email address being potential duplicates. Users are presented with a notification on the Salesforce User Interface (UI) from which they can take remedial action such as discarding the record they are on (or the potential duplicate) or merging record information together.
When it comes to the inputting of data, validation rules can be utilized to ensure that formulaic conditions are met in order to prevent record creation or updates, making users adhere to a specific format when entering correct data. For example, if a lead is being progressed beyond a certain stage, validation rules can be used to ensure that a certain industry field is selected or a valid phone number has been entered (down to the format). Secondly, picklists (predefined lists of values) can be used to limit the values a user can enter against a record. When picklists are used over free-text values, users are restricted (in a good way) to selecting values from managed lists. Reporting and searching are made quicker and easier as a result. There is also the concept of dependent picklists, whereby the values in one picklist are filtered or restricted based on another. This again can be used to direct users to select from specific value sets in order to drive data quality. Those value sets can be shared across multiple picklists to ensure consistency in the values chosen (as the underlying values are shared and managed centrally).
Salesforce has declarative automation in the form of workflow rules and flows. Workflow rules can be thought of as a container for a set of instructions for automating actions based on defined criteria (which can be time-bound), such as sending emails or updating fields. These instructions can be thought of as taking an if this, do that format.
Flows can be used to perform certain record operations in order to drive consistent behavior with regard to data. For example, when an account is created, a flow can run to ultimately trigger an outbound call to a credit agency to pull in credit rating information about the company to whom the account record pertains.
Next up in the category of automation is approval processes. This feature of the Salesforce Platform facilitates record changes being submitted for approval by a users manager, a named user, or a group of approvers. Approvals can be configured (so that only one of a group or a whole group needs to approve the request) and provide a virtual paper trail of changes that take place. For example, a salesperson attempting to apply a discount on a quote above a certain threshold may require approval from the Sales Director. Salesforce's approval process mechanism is a perfect fit for this type of behavior.
Lastly, data cleansing may also be required. Salesforce doesn't contain native data-cleansing capabilities, but AppExchange packages and external tools exist that facilitate either the real-time cleansing, enrichment, and deduplication of data either in situ on the platform (in the case of an AppExchange package) or off-platform, where an export/import of data is required (in the case of a fully-fledged offline tool).
While data-cleansing capabilities per se aren't native to the platform, there are a few field types and configuration options that can be exploited to make life a little easier when it comes to categorizing, cleansing, and deduplicating data. These typically are picklists, checkboxes, and lookup filters.
In short, picklists are used to restrict input to one of a set of predefined values (which can be global value sets for org-wide uniformity in options). Checkboxes are for true/false value selection, and lookup filters can ensure that the range of values to be selected is reduced to those that are determined applicable based on filtering criteria.
When developing a data management strategy, it may be wise to consider what kinds of conventions to instill (and apply reporting and validation on if possible). For example, always abbreviate the suffix Limited to Ltd for United Kingdom (UK) companies. While this is an overly simplistic example, the principle is that consistency in which data is created, updated, and viewed ensures that confusion doesn't result when working with data and that data can be kept in a consistent state.
This then leads us nicely on to how data quality is monitored. A plan should be designed from the outset to determine how data is identified and the strategy of how it will be dealt with, down to the assignee and owner of such activities. For example, the sales team is required to ensure that all incomplete lead records are reviewed and updated to conform to data completeness or formatting requirements by the business at the end of every month. That way, the team knows that it starts each month with a better dataset than what it finished the previous month with.
Now that we've covered how data can be persisted in a consistent manner on the Salesforce Platform, we can now look at how Salesforce addresses the concept of a single view of a customer on its platform.
Representing a single view of the customer on the Salesforce Platform
A single view of the customer (sometimes called an SCV, but meaning exactly the same thing), represents a unified 360° view of each customer. As explained in Chapter 3, Master Data Management, an integration layer can be used to produce a golden record whereby it consolidates data from multiple sources (using an Identifier (ID) registry or IDs in Salesforce against a record). Additionally, data cleansing, deduplication, and enrichment can be included in the process of bringing customer data together.
As you may or may not know, not all Salesforce clouds are on the same underlying infrastructure, and therefore Salesforce produces various connectors and accelerators to overcome this. Examples include the following:
- The Marketing Cloud connector—connects Marketing Cloud and Sales Cloud
- The Pardot connector—connects Pardot and Sales Cloud
- MuleSoft accelerators and connectors for Commerce Cloud (B2B and B2C)
Salesforce brings various technologies and connectors together to form an offering called Customer 360. For example, a global profile can be built by consolidating data from multiple Salesforce clouds using connectors and MuleSoft as an integration platform. For example, a customer's B2C Commerce Cloud profile, Service Cloud profile, Experience Cloud profile, Marketing Cloud profile, and external system data can all be consolidated under a single global profile ID. An example of this is the Salesforce Architecture for Retail, found at https://help.salesforce.com/s/articleView?id=sf.icx_b2c_solution_architecture_overview.htm&type=5.
Let's now take a look at the different elements of the Customer 360 platform.
Elements of the Customer 360 platform
There are several areas of the Customer 360 platform that are useful for the Data Architecture exam. These are explained next.
Salesforce Customer 360 Data Manager
Customer 360 Data Manager is a Salesforce solution for connecting customer-centric data across Salesforce products, Salesforce instances, Commerce Cloud B2C instances, and other data sources. Data is surfaced through one view, to provide a single view of the customer.
Salesforce then layers on Einstein dashboards that provide data-validation capabilities. Source record data that has been matched to form a global profile can be managed from a single location, including editing and deleting source data.
There is also the concept of a Cloud Information Model (CIM) that maps data to a common schema. This provides a single representation of that data in connected data sources.
Salesforce technologies such as Marketing Cloud, MuleSoft, and Commerce Cloud form part of a Data Manager solution, as data points exposed in these technologies form the data points of the customer representation.
These concepts should be familiar given the concepts and theory we covered in Chapter 3, Master Data Management.
Next up, let's look at Customer Identity.
Salesforce Customer Identity
Salesforce Customer Identity is a name given to a suite of technologies that allow (from an Identity and Access Management, or IAM, perspective) customers and partners to access your Salesforce instance and interact with your brand. Salesforce Identity concepts apply here, with the addition of Experience Cloud sites as the means upon which your brand is interacted with. As you may already know, Experience Cloud sites can be set up to use Open Authentication (OAuth), Single Sign-On (SSO) (if not through an OAuth provider such as Facebook or Google), and passwordless login. It's also possible to use Customer Identity to embed a login experience into an existing website (such as an e-commerce site at the checkout stage). This provides a touchpoint to customers and allows for the collection of information such as an email address, currency preference, and so on.
This functionality requires External Identity or Community license types.
Lastly, let's investigate the Customer Data Platform (CDP).
Salesforce CDP
In what can be thought of as an evolution of the traditional Customer Relationship Management (CRM) system, Salesforce CDP layers on engagement information (from Marketing Cloud) and buying information (from Commerce Cloud), along with integrated data sources using MuleSoft. In a nutshell, it is used to unify and segment data so that experiences for customers that are powered by the Salesforce Platform can be targeted and personalized to them. Customers can be engaged using their preferred channels and have a personalized experience that transcends sales, service, commerce, and marketing because these technologies are all connected, and the single view of the customer is exposed through the Salesforce Platform.
Now that we've explored how we can represent a single view of the customer on the Salesforce Platform, let's now look at how an important part of that process—data from multiple Salesforce instances—can be achieved.
Pulling together data from multiple Salesforce instances
Salesforce data architects must be able to design how to effectively consolidate, process, and leverage data from multiple Salesforce instances. While there are pros and cons of using multiple Salesforce instances within the boundaries of an Information Technology (IT) enterprise, there are instances where knowing how to best leverage the data from those multiple instances together across the IT enterprise can unlock value for your users. Salesforce offers several options or solutions in bringing data from several instances of Salesforce. These can include the following:
- Salesforce Connect
- Salesforce to Salesforce
- Bulk API
- Batch Apex
These are explained in the following sections.
Salesforce Connect
As explained in Chapter 3, Master Data Management, Salesforce Connect is a method for pulling in data from external data sources, using the OAuth 2.0 protocol, OAuth 4.0 protocol, or a custom Apex adapter for external data access.
Salesforce Connect is useful for surfacing data that isn't mastered in Salesforce yet can form part of the Single Source Of Truth (SSOT). Consider a financial institution that has bank account information in Salesforce. Given the relative frequency in which transactions on a bank account may occur, it may make sense to surface that data on demand rather than store the transactions in Salesforce. This is a perfect use case for Salesforce Connect.
Read more about Salesforce Connect at https://help.salesforce.com/s/articleView?id=sf.platform_connect_about.htm&type=5.
Salesforce to Salesforce
Salesforce to Salesforce is a technology that's used to share data across Salesforce instances. Essentially, a connection is made between Salesforce instances, and then data sharing is set up so that users can see shared data and updated information from another Salesforce instance in their own Salesforce instance. Users only have access to shared records as they are mapped to records in their own org, and therefore the original data records in the external Salesforce org aren't directly accessible to users in your org. Custom reports can be created to report on external data. Field subscriptions can also be set up to map fields in an external Salesforce instance to fields in your Salesforce instance.
Salesforce to Salesforce is useful in scenarios such as a company that has different divisions that cannot or do not share business logic. This may be since the company has made a merger or acquisition or has a group structure, such as rolling up sales data from one Business Unit (BU) to a parent or group BU. Salesforce to Salesforce can be one-directional or bi-directional in terms of information transfer.
More information on Salesforce to Salesforce can be found at https://help.salesforce.com/s/articleView?id=sf.business_network_intro.htm&type=5.
Bulk API
Salesforce Bulk API (version 2.0 at the time of writing) is a Representational State Transfer (REST)-based Salesforce-specific Application Programming Interface (API) used to asynchronously read, upload, or delete large quantities of data on the Salesforce Platform. A good rule of thumb is that any datasets of 2,000 records or more are suitable candidates for Bulk API operations. As per Salesforce's documentation at https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm, datasets of fewer than 2,000 records should be used with bulkified synchronous API calls (adhering to governor limits, using either REST or Simple Object Access Protocol (SOAP) protocols with the Salesforce Platform).
Addressing the question of using Bulk API for the bringing together of data from multiple instances, this API is a candidate for cases where large amounts of data are moved from one instance of Salesforce to another. Requests are processed asynchronously, with Salesforce returning a job ID upon accepting the request that can be queried for periodic updates of the status of the job.
Read more on getting started with Bulk API at https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_quickstart.htm.
Batch Apex
Complex, long-running processes that run on the Salesforce Lightning Platform can utilize a technology called Batch Apex. Essentially, large datasets are queried, broken down into manageable chunks of data, and then processed. It is commonplace to perform whole data-type operations on a nightly basis as Batch Apex, such as processing and archiving all accounts that have had no activity past a certain date. Batch Apex utilizes the Database.Batchable interface and the Apex scheduler can be used to facilitate a Batch Apex class being run at certain times (such as hourly or nightly).
Batch Apex lends itself well to scenarios that call for business-logic operations that need to work with lots of data. In the UK, educational institutions and schools are regularly inspected by a regulatory body. Imagine that schools, inspectors, and information such as holidays booked by inspectors and term dates of schools are all held in Salesforce. A nightly Batch Apex job is the perfect candidate to initiate and process the data when scheduling inspections for schools, which could in theory require processing down to the area an inspector is responsible for.
Read about using Batch Apex at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_batch_interface.htm.
Important note
Batch Apex is an interface: Batch Apex is exposed as an interface that requires a developer to write an implementation for. Therefore, Apex coding skills are required for Batch Apex operations as they require running queries and processing using bespoke code.
As we delved into in Chapter 3, Master Data Management, an SSOT approach can be defined and then used to consolidate data when presenting data to users. This may manifest itself in a golden record. One such example for data consolidation whereby data is brought together from multiple data sources and forms a single view of the customer is Salesforce Customer 360 Data Manager, as explained earlier in the Representing a single view of the customer on the Salesforce Platform section.
Summary
In this chapter, we covered a range of topics related to data on the Salesforce Platform. We started by looking at licensing and how different types of licenses affect the solutions we build as Salesforce architects. Different license types afford different object/entity access and functionality. For example, the Service Cloud license allows for entitlements and milestones, meaning it facilitates an SLA mechanism. Without this license, users don't have access to the entities for entitlements and milestones.
We also looked at external user access to the Salesforce Platform through the use of Experience Cloud license types. We covered the differences afforded in terms of object access and sharing functionality and looked at the different use cases for each license type for Experience Cloud.
You may have questioned why licensing was important to cover at the start of this chapter, but by now, you'll hopefully appreciate that licensing can have a profound impact on the data access of the solutions we architect.
Next, we looked at data persistence. We revisited the concept of an SCV on the Salesforce Platform, bringing in our knowledge from Chapter 3, Master Data Management, and understood how Salesforce addresses the notion of a single customer through its product suite.
We also built upon knowledge acquired in Chapter 3, Master Data Management, in bringing together data from multiple Salesforce instances, covering the options available to us to achieve this.
In Chapter 5, Data Governance, we'll look at how data on the Salesforce Platform can be safeguarded and governed, including visiting the concepts that underpin compliant solutions.
Practice questions
- Which Experience Cloud license type is required in B2C scenarios where access to reports is required?
- Which Experience Cloud license type exposes the Quote object?
- Which Experience Cloud license type is required for access to Knowledge?
- Which Experience Cloud license type only facilitates record sharing through sharing sets?
- Which Experience Cloud license type allows for the creation of dashboards?
- Which Experience Cloud license types allow for sharing rules?
- Which Experience Cloud license type allows for the creation of reports?
- Which Experience Cloud license type exposes the Lead and Opportunity objects?
- Which technology is used to surface external data in Open Data Protocol (OData) 2.0 or OData 4.0 format?
- Which technology is used to process and execute long-running Apex operations across entire datasets on the Salesforce Platform?
- Which technology is used to read, upload, or delete large datasets on the Salesforce Platform?
- Which technology is used to surface data in one Salesforce instance to another Salesforce instance?
- Customer 360 is a Salesforce solution designed to provide what?
- Marketing Cloud and Salesforce are connected using what?
- What is the recommended technology to bring together data from external data sources on the Salesforce Platform as part of Customer 360?
Answers
- Customer Community Plus
- Partner Community
- Customer Community
- Customer Community
- Partner Community
- Partner Community and Customer Community Plus
- Customer Community Plus
- Partner Community
- Salesforce Connect
- Batch Apex
- Bulk API
- Salesforce to Salesforce
- A 360° view of the customer
- The Marketing Cloud connector for the Salesforce Platform
- MuleSoft
Further reading
Salesforce Experience Cloud licensing:
Setting up sharing sets:
https://help.salesforce.com/s/articleView?id=sf.networks_setting_light_users.htm&type=5
Salesforce data storage allocations:
https://help.salesforce.com/s/articleView?id=sf.overview_storage.htm&type=5
CDP:
https://www.salesforce.com/ap/solutions/customer-360/
Salesforce to Salesforce:
https://help.salesforce.com/s/articleView?id=sf.business_network_intro.htm&type=5
Introduction to Bulk API 2.0:
https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm