Let’s dive straight into the design thinking needed to design a Salesforce application.
Salesforce’s licensing model and how to choose the right licenses
Comparisons of the common Salesforce products
How to choose the right features of Salesforce and when to use declarative vs. programmatic capabilities to design an application
The order of execution of Salesforce events
Considerations and strategies for a multi-org vs. a single-org environment of Salesforce
Different ways to extend Salesforce capabilities by utilizing third-party apps available in Salesforce’s AppExchange marketplace
When to consider managing functionalities off the Salesforce platform and how to integrate with off-platform services to work seamlessly with Salesforce
Salesforce Licenses
Salesforce’s licensing model can be complex and nonintuitive at first. Choosing the appropriate licensing model is crucial to design a Salesforce solution since it almost entirely determines what any user can or cannot do within Salesforce. Different Salesforce licenses enable or restrict access to different Salesforce features and objects.
Org-level licenses
User-based licenses
Permission set–based licenses
Feature-based licenses
Usage-based entitlements
Salesforce regularly updates and changes product names, features, and limitations. It is vital to work directly with your Salesforce account executive or program architect before purchasing licenses.
Org-Level Licenses
Org-level licenses are also often referred to as Salesforce editions.1 This is the type of license that a company needs to select for the first time. The org-level licenses determine the infrastructure resources such as storage and API access assigned by Salesforce to your company. The editions also determine the level of SaaS or PaaS functionalities that will be available to that environment (org) of Salesforce. Salesforce offers five org-level license editions. For business use, typically, the editions start with the Essentials Edition (ES), and each edition above that is an upgrade from thereon. The only exception to editions is the Developer Edition (DE), a free edition available to anyone with features similar to the Enterprise Edition (EE) licenses. The Developer Edition is primarily meant for use by developers and third-party vendors who intend to build apps for Salesforce’s AppExchange ecosystem (more on AppExchange later in this chapter) or anyone just interested in exploring Salesforce for free.
- 1.
Essentials Edition (ES)
- 2.
Professional Edition (PE)
- 3.
Developer Edition (DE)
- 4.
Enterprise Edition (EE)
- 5.
Unlimited Edition (UE)
Salesforce License Editions
For a more detailed comparison of the editions, please refer to www.salesforce.com/editions-pricing/sales-and-service-cloud/.
An org-level edition license is required for every org of Salesforce, and every Salesforce org can only belong to one edition of Salesforce.
The edition applies to the entire org and all licenses within that org.
You can switch from a lower edition of Salesforce to a higher edition, but you cannot downgrade from a higher edition to a lower edition. (Example: You cannot switch from a Professional Edition to an Essentials Edition.)
User Licenses
Just like an org-level license, user licenses determine to which each user within your org has access. A user license is required for each user accessing your org.
- 1.
Chatter licenses
- 2.
Salesforce licenses
- 3.
Salesforce platform licenses
- 4.
External Identity licenses
- 5.
External Apps licenses
- 6.
Customer and Partner Community licenses
Chatter Licenses
Chatter licenses are licenses, available with all standard Salesforce licenses, that only give the assigned user access to Salesforce’s collaboration feature known as “Chatter” similar to the user experience within Facebook or LinkedIn. Chatter licenses are meant for one thing and one thing only, that is, collaboration with other Salesforce users.
- 1.
Chatter External
- 2.
Chatter Free
- 3.
Chatter Only
Chatter External Licenses
These licenses are meant for external users such as prospects, customers, partners, and anyone outside of your organization’s domain. Users with these licenses do not have access to any Salesforce objects or data stored within your Salesforce org. They can only see and post messages within chatter groups that they are invited.
Chatter Free
As the name suggests, Chatter Free licenses are free user licenses that can be assigned to any internal user within your organization’s domain that does not need a paid user license to use Salesforce but needs to collaborate with all Salesforce users within your org. These users can access basic Chatter items such as people, profiles, groups, and files posted in chatter posts, but they cannot access any Salesforce objects or data. However, Chatter Free users can be given moderator permissions to moderate any chatter group(s).
Chatter Only License (Also Known as Chatter Plus)
- 1.
View-only access to account and contact objects.
- 2.
View and edit up to ten custom objects.
- 3.
View reports and dashboards.
- 4.
Be assigned as an approver and approve an approval process of Salesforce.
- 5.
Be assigned to tasks by other users.
- 6.
Create/view/edit their own events, activities, and tasks.
- 7.
Add any records they access to within chatter groups that they are part of.
- 8.
Use Salesforce CRM content, ideas, and answers.
Salesforce Licenses
Salesforce licenses are only available for internal users within your enterprise. They provide access to Salesforce’s SaaS-based Customer Relationship Management (CRM) products, which primarily include Sales Cloud, Service Cloud, and Lightning CRM Cloud. In order to access any standard CRM application within Salesforce, these licenses are required.3
The Lightning CRM Cloud license includes all Sales Cloud and Service Cloud features. The Service Cloud license includes most features of Sales Cloud except for a few features and standard objects that are only available with Sales Cloud licenses (or the Lightning CRM licenses) such as quotes and sales contracts. However, Service Cloud has many more features and standard objects that are not available in Sales Cloud, such as entitlements, work orders, and service contracts. A good resource to identify which objects are available with Sales Cloud vs. Service Cloud is the data model section within Salesforce’s officially published SOAP API Developer Guide.4
In addition to the Sales, Service, and Lightning CRM Cloud licenses, Salesforce offers add-on products that can be paired either with a Sales Cloud or a Service Cloud license. Some common add-on products requiring at least the Sales Cloud license are Salesforce CPQ, Pardot, and Financial Services Cloud, and the add-on product requiring at least the Service Cloud license is Salesforce Field Service Lightning. For a detailed list of all add-ons that can be paired with Salesforce licenses, please refer to Salesforce Add-on Pricing sheet on Salesforce’s official website.5
Salesforce Platform Licenses
Salesforce platform licenses are also only available for the internal users within your enterprise. They provide access to the platform of Salesforce with access limited to the core standard objects (also known in the industry as “Hero” objects) of Salesforce. These core objects are accounts, contacts, cases, activities, tasks, events, content, and documents. Salesforce platform licenses come in two types of offerings: Lightning Platform Starter and Lightning Platform Plus.
Only cases related to internal users are allowed, and any cases related to external users are contractually prohibited.
The main distinction between the two platform offerings is the limit on the number of custom objects that can be created with each type. With the Lightning Platform Plus license, you can create up to 110 custom objects, whereas with the Lightning Platform Starter license, you can only create up to ten custom objects. These custom objects are in addition to the standard core objects available with both options.
External Identity Licenses
External Identity licenses offer a Customer Identity and Access Management (CIAM) solution specifically to manage the identity services of external users. It is a standalone license offered by Salesforce to allow your external users to authenticate via standard username/password, passwordless logins, or social sign-on or even act as a single sign-on service for the external apps exposed to them.
The External Identity license provides access6 to the following standard objects (mostly in read-only mode): accounts, assets, contacts, documents, individuals, and files. Salesforce allows the creation of up to ten custom objects with this license type.
External Apps Licenses
Salesforce’s External Apps licenses are similar to the Salesforce platform licenses but for external users of your enterprise. Salesforce has contractual restrictions that prohibit assigning the earlier indicated Salesforce licenses or the Salesforce platform licenses to any user external to your enterprise. For external users who need access to your Salesforce platform capabilities and not to the Salesforce CRM capabilities, you can assign External Apps licenses to these external users. We will talk about the Salesforce CRM capabilities in a later section when we talk about Customer and Partner Community licenses.
External App licenses can be assigned uniquely for each user as a named user license or as usage-based entitlements, which are based on the number of user logins per month. More on user license types covered a bit later in this chapter.
Similar to earlier indicated Salesforce platform licenses, External Apps licenses are available in two types of offerings: Lighting External Apps and Lightning External Apps Plus. The distinction between the two types of offerings is identical to the distinction between Lightning Platform Starter and Lightning Platform Plus offerings of Salesforce platform licenses. However, it is important to note that External Apps licenses cannot be purchased and utilized independently. External Apps licenses are dependent on having at least a Salesforce or Salesforce platform or External Identity license in the org.
Customer and Partner Community Licenses
Needless to say, Customer and Partner Communities are licenses for external users such as your customers and partners, providing them access to the standard and custom applications that you wish to expose to them for support and self-service. As of this writing, Salesforce has renamed their Community Cloud product to “Experience Cloud.”7
Salesforce has renamed their Community Cloud product to Experience Cloud.
High-Level Comparison of Experience Cloud Licenses
For further reading on Salesforce community licenses, we would highly recommend the book Practical Guide to Salesforce Communities by Philip Weinmeister (Apress, 2018). Here, once again, it is important to note that, similar to External Apps, Experience Cloud licenses are dependent on having at least a Salesforce or Salesforce platform or External Identity license in the org.
Experience Cloud (formerly known as Community Cloud)licenses are dependent on having at least a Salesforce or Salesforce platform or External Identity license in the org.
Permission Set Licenses
Permission set licenses were first introduced in the winter 2014 release. The primary objective of permission set licenses was to allow the assignment of add-on licenses to a single user. Add-on product offerings such as Salesforce Field Service Lightning, Salesforce CPQ, Salesforce Health Cloud, and Salesforce Financial Services Cloud can be added in addition to your Salesforce licenses.
Salesforce Licenses and Common Add-On Permission Set licenses
Figure 3-3 is only a point of view on common Salesforce licenses. As Salesforce is evolving its products, the point of view is subject to change.
For specific details on licenses and add-ons, please refer to Salesforce’s official website. Salesforce also used to publish a license comparison pdf document, the URL for which keeps changing . To find this document, we recommend a quick search online with the following keywords: Salesforce User License Comparison PDF.
Feature Licenses
11 Salesforce Feature Licenses8
Feature License | What Does It Enable the User to Do? |
|---|---|
Chatter Answers User | To access “Chatter Answers.” This feature license is automatically assigned to high-volume portal users who self-register for Chatter Answers. |
Flow User | To run Lightning Flow. |
Knowledge User | To access Salesforce Knowledge. |
Chat User | To access chat. |
Marketing User | To create, edit, and delete campaigns, configure advanced campaign setup, add campaign members, and update their statuses with the Data Import Wizard. |
Offline User | To connect offline. |
Salesforce CRM Content User | To access CRM content stored within Salesforce. |
Service Cloud User | To access the service console within Service Cloud. |
Site.com Contributor User | To edit content published on Site.com Studio. |
Site.com Publisher User | To create and style websites, control the layout and functionality of pages and page elements, and add and edit content on Site.com Studio. |
WDC User | To access work.com objects and features. |
Usage-Based Entitlements
Salesforce offers a usage-based licensing (also commonly referred to as “login-based licenses ” for products such as Salesforce communities and External Apps) model as an alternative to purchasing a named license for each and every user in the org. With usage-based entitlements, a company purchases lump-sum credits for a number of logins per month for their users or for a number of transactions per month, such as in the case of data.com9 (i.e., Salesforce’s data quality and data integrity management service). With usage-based entitlements, a company can overallocate these licenses to any number of users. However, users with these licenses get access to Salesforce on a first-come-first-served basis until the number of logins per month or the transaction limits allocated are reached for that month.
Usage-based entitlements are most popular with assigning Salesforce Experience Cloud (formerly known as Community Cloud) licenses. From the external user’s perspective, the experience is no different whether they are assigned a named user license or a usage-based entitlement license. When deciding whether to assign a named user license or a usage-based entitlement. For users accessing Salesforce more than three times per month, usage-based licenses may not have any cost savings over a named user license .
Assign a usage-based license where you have a large volume of one-time uses or very low use assignments. This is common for customer communities and service communities. A rule of thumb to follow is to assign a usage-based entitlement to any user that logs into Salesforce three times or less per month.
Platform vs. CRM Licenses
Comparisons Between Platform, Sales, and Service Cloud Licenses
Product Type | Considerations | Limitations |
|---|---|---|
Platform | Cheapest license for internal users. Access to Hero objects + up to 110 custom objects. Access to internally generated standard cases and work orders. Account teams can be enabled and used. | No Bulk API or Streaming API. No access to external cases and external work orders. No access to campaigns, leads, opportunities, orders, products, pricebooks, assets, contracts, quotes, entitlements. No opportunity teams or case teams. No forecasting. No omni-channel. No live agent. Can use but cannot create workflows, approval process, Process Builder, flows, or any Apex code. |
Sales Cloud | Includes everything available with platform licenses. Access to all standard CRM objects and features except for entitlements and service contracts. Access to sales contracts, quotes. Omni-channel only available for leads, order, and any custom object with no parent object. Territory management feature. Opportunity split feature. Required for add-ons such as CPQ, Pardot, and Financial Services Cloud. | No access to entitlements, service contracts. Omni-channel not available for cases, contact requests, chat, social posts. SOS feature not available. |
Service Cloud | Includes everything available with platform licenses. Access to all standard CRM objects and features except for quotes and sales contracts. Full omni-channel capabilities. SOS feature available (in Classic only). Required for add-ons such as Field Service Lightning. | No access to quotes, sales contracts. No territory management. No opportunity splits. |
Lightning CRM | Most expensive license for internal users. Includes everything available with platform and Sales and Service Cloud licenses. Up to 2000 custom objects allowed. | None. |
Experience Cloud (formerly known as Community Cloud: Used to provide access to external users
Marketing Cloud and Pardot: Designed to manage B2C and B2B marketing efforts
Field Service Lightning: Adds features to Service Cloud specific to outbound service resources
CPQ: Developed to support the configuration, pricing, and quoting process
B2B and B2C Commerce Cloud: Supports the presentation and transactions associated with online storefronts
Tableau CRM Analytics (previously known as Einstein Analytics): Provides advanced data analytics
Financial Services Cloud: Integrates financial functionality, such as accounting
Health Cloud: Incorporates both patient cares and medical operations
Nonprofit Cloud and Education Cloud: Provides support for grants managements and education-related features such as admissions and registration
Quip: Enables collaboration
Work.com (Including the New Version with Pandemic Support): Designed to support an ever-changing working environment
Heroku: Delivers a PaaS to create, deliver, and manage on the cloud
MuleSoft: Provides an integration platform
Salesforce Application Design Choices
Salesforce has hundreds of out-of-the-box features that can be configured to design a business application out of the box. However, as an architect, you should at least be familiar with the 18 most common declarative options and the 16 most common programmatic options available to design any application on the Salesforce platform.
Application Design Options Based on the Technical Context of Requirements
Now let’s discuss each option in a bit more detail.
Common Declarative Options
Declarative Development Options Available in Salesforce
Declarative Options | Description |
|---|---|
Page layouts | Page layouts control the display and organization of the user interface, including buttons, fields, any Visualforce pages embedded within the page, custom links, and related items for each object. They also help determine which fields are visible, read-only, and required. Each page layout can be assigned directly to one or more user profiles, which defines the view of that object detail for the users in the assigned profile. Technical context for this option: Interface context |
Lightning app | A Lightning app is a collection (i.e., folder) of record pages and user features that work together to serve a particular user function. Lightning apps can be branded and customized along with including utility bars at the bottom of the page and custom design the navigation of other tabs and related sub-tabs. Technical context for this option: Interface context |
Record types | Record types allow configuring different business processes, picklist values, and page layouts for different users that use the same object differently (e.g., opportunities for different business lines). Technical context for this option: Interface context and/or business logic context |
Workflow | A workflow rule is a set of business logic defined using an if/then criterion that executes when a specified data change (user-defined criteria) occurs in Salesforce or is triggered at a specified recurring time. With workflow, users can create new tasks, send emails, update fields, send an outbound message to another system, and initiate a flow. Technical context for this option: Data context and/or business logic context |
Process Builder | Process Builder can be used to do everything that can be done using workflow EXCEPT FOR sending outbound messages (i.e., declarative web service messaging from Salesforce to an external system). Additionally, Process Builder provides a graphical drag/drop interface to design the business processes related to each object. Compared to workflow rules, Process Builder can also update child records, post to Chatter, auto-submit records in the approval process, and invoke Apex classes. Technical context for this option: Data context and/or business logic context |
Flow | Flow can be easily defined as the most declarative way of creating code through a graphical drag and drop user interface. A single Lightning Flow is an application that automates a business process by collecting data and executing actions within your Salesforce org or directly in an external system from within Salesforce. It is the most powerful declarative tool among all and compared to workflow rule and Process Builder. This is a great choice when the business logic is complicated or it requires accommodating an if/then data logic and something that also requires user interaction. However, a flow can be an overkill if a single or couple of fields need to change or the business logic is straightforward. Technical context for this option: Any or all three |
Assignment rules | Assignment rules can only be used with leads and/or case objects. It defines the rules and assigns a lead or a case to the appropriate user or a queue that manages leads or cases. Technical context for this option: Business logic context |
Escalation rules | Escalation rules can only be used with the CASE object. It defines the criteria under which a case gets escalated to a supervisor of the current case manager. It could be based on case status, case field changes, or time-lapse in case status changes. Escalation rules are primarily useful when certain service-level agreements need to be met by support agents. Technical context for this option: Business logic context |
Approval process | Approval processes can be set up to automate any record approvals needed in Salesforce. An approval process specifies each step of approval, including from whom to request approval and what to do at each step of the approval process (e.g., discounts higher than 25% might require the approval of a senior manager). Technical context for this option: Business logic context |
Formula fields | Formula fields are READ-ONLY fields, the value of which is evaluated based on the value of other existing fields (e.g., calculate totals, concatenate two or more fields to create a combined text, calculate dates including current date, etc.). Technical context for this option: Interface context and/or business logic context |
Validation rules | Validation rules verify that the data a user enters for a record meets various data criteria needed for data quality, such as required fields, data logic such as no past dates allowed or amount not greater than another amount field, and so on. A validation rule can contain a formula or expression that evaluates the user-entered data in one or more fields and returns a value of “True” or “False.” Technical context for this option: Data context and/or business logic context |
Roll-up summary fields | Roll-up summary can ONLY BE USED on the master object of objects connected with each other via a master-detail relationship. Roll-up summary fields calculate values from related child object records (e.g., display the sum of invoice amounts for all related invoice custom object records in an account’s invoices-related list). Technical context for this option: Interface context and/or data context |
Sharing rules | Sharing Rules are user access control features defined within Salesforce that dictates a specified users access to the data based on record ownership rules, based on specific data criteria, sharing record with a group of users, different roles and their subordinates, users and their subordinates in a different territory. Sharing rules can be defined to provide read-only or read/write access to any record. Technical context for this option: Data context and/or business logic context |
Custom objects | Custom objects are the key to extending Salesforce beyond the standard object capabilities. Every custom object automatically gets assigned a page layout out of the box that renders a user interface. In addition to the user interface, it inherits many of the platform capabilities available to all objects within Salesforce. For this reason, a custom object can be used to serve any technical context. Technical context for this option: Any or all three |
Custom fields | Salesforce allows you to create 23 different types of custom fields for any object. The choice of custom field not only determines the data type that is acceptable for input but also provides several other capabilities such as the ability to generate auto-numbers and the responsiveness to open hyperlinks in a separate window. Custom fields are also an option to address any technical context. Technical context for this option: Any or all three |
Platform events | Platform events allow you to connect Salesforce to a remote system(s) based on the publish/subscribe event-driven architecture. In an event-driven architecture, a message is published to an event bus, and subscribers of that message connected to the event bus can consume the data. The subscribers can be a Lightning app within your org or an external remote system. There are two types of platform events that can be configured within Salesforce, that is, Change Data Capture events and Standard Platform events. With “Change Data Capture” events, you can publish change events, representing any changes occurring to Salesforce records within your org. Changes include record creation, updates to an existing record, deletion of a record, and undeleting a record. With Standard Platform events, you can set up an action that publishes a set of predefined data within a platform event object. Any data stored within the platform event object is then published to the event bus. Technical context for this option: Any or all three |
Canvas | Canvas is Salesforce’s capability to integrate with a remote application via a Data Virtualization pattern (for more details on data virtualization integration, refer to Chapter 6). Canvas is a set of tools that utilizes JavaScript APIs to expose the remote application seamlessly within your Salesforce org as part of your Salesforce user interface. Technical context for this option: Interface context |
Salesforce Connect | Salesforce Connect can be configured to access data from external sources, along with the Salesforce data within your org. With Salesforce Connect, you can display data from external systems as external objects within Salesforce. External objects are similar to custom objects, except that they map to data located outside your Salesforce org. Salesforce Connect maintains a live connection with the external data stored in the external system such that the data reflected in the external objects within your Salesforce org is up to date. With Salesforce Connect, you can • Query data in an external system. • Create, update, and delete data in an external system. • Access external objects via list views, detail pages, record feeds, custom tabs, and page layouts. • Define relationships between external objects and standard or custom objects to integrate data from different sources. • Enable Chatter feeds on external object pages for collaboration. • Run reports on external data. • View the data on the Salesforce mobile app. Technical context for this option: Interface context and/or data context |
Common Programmatic Options
Development Options Available in Salesforce
Programmatic Options | Description |
|---|---|
Visualforce page | A Visualforce page is similar to a standard web page, but includes additional features to access, display, and update any data from the Salesforce org. Pages can be referenced and invoked via a unique URL specifically assigned to each Visualforce page created. Technical context for this option: Interface context |
Lightning components | A Lightning component is a UI framework (i.e., “Aura” framework) that allows for developing single-page applications for mobile and desktop devices. Unlike Apex classes, Lightning components have decoupled code resources for reusability and better code execution on the browser or the mobile app (i.e., client-side application). Technical context for this option: Any or all three |
Lightning web components (LWC) | Lightning web components are custom HTML elements built using HTML and modern JavaScript. Lightning web components and Lightning components can coexist and interoperate on a page. Technical context for this option: Any or all three |
Apex class | An Apex class contains the programmatic code to execute behaviors and manage the state of any object within Salesforce. Similar to Java, an Apex class is a template or blueprint from which objects are created. An Apex class can also be written to act as a controller, which is a set of instructions that specify what the Salesforce server should do when a user or remote system interacts via an interface. Controllers can be standard controllers that contain the same functionality and logic used for standard Salesforce pages; or a developer can build custom controller classes or controller extensions using Apex to override existing standard functionality, to customize the navigation through an application, to use callouts or web services, or if you need finer control on how information is accessed from a page. Technical context for this option: Any or all three |
Triggers | Triggers are Apex scripts written related to any object, where users need to perform custom actions before or after changes are saved for any records such as insertion of new record, updates to existing records, or deletions of existing records. There are two types of triggers: before triggers and after triggers. A before trigger is used to update or validate record values BEFORE they’re saved to the database. On the contrary, after triggers are used to access field values that are set by the system (such as a record’s ID or LastModifiedDatefield) after the record has been saved in the database and to make changes to related records. Technical context for this option: Any or all three |
Metadata API | Metadata API can be used by users to retrieve, deploy, create, update, or delete customizations within any org using the Force.com IDE or Ant Migration Tool or an external code scripting tool such as Microsoft VS Code. The most common use is to migrate changes from a sandbox or testing org to the production environment. Metadata API is intended for managing customizations and for building tools that can manage the metadata model, but not the data itself. Technical context for this option: Interface context and/or business logic context |
Tooling API | With Tooling API, you can build custom development tools or custom apps to use with Salesforce. Tooling API is similar to Metadata API, such that you can access and update the Salesforce metadata with it, except that the SOQL queries used with Tooling API can retrieve smaller pieces of metadata. Smaller retrieves of metadata can improve performance, hence making Tooling API a better fit than Metadata API for developing interactive applications that connect with your Salesforce org. You can use Tooling API to add features and functionality to your existing Lightning Platform tools. Technical context for this option: Interface context and/or business logic context |
SOAP API | Salesforce’s SOAP API provides programmatic access to your org’s information using a simple, powerful, and secure Application Programming Interface. Users and external systems can use SOAP API to create, retrieve, update, or delete records, such as accounts, leads, and custom objects. With more than 20 different calls, SOAP API also allows users to maintain passwords, perform searches, and more. Technical context for this option: Data context |
REST API | Salesforce’s REST API can be used for field-level changes especially when users are using Salesforce via mobile applications and heavy UI-based web applications. Rest API is best for making field changes when the total number of records to be updated is less than 20 in a single call. For large data volume updates, users can also use Bulk API which uses the REST protocol similar to REST API for integration. With Rest API, external systems as well as mobile and web applications can access all Salesforce objects that are accessible via SOAP API. Technical context for this option: Data context |
Bulk API | Bulk API is based on REST principles and is optimized for loading or deleting large sets of data. You can use it to query, queryAll, insert, update, upsert, or delete many records asynchronously by submitting batches. Salesforce processes batches asynchronously in the background. Technical context for this option: Data context |
User Interface API | User Interface API is mainly used to replicate all or part of a Salesforce user interface based on some criteria and/or permissions defined for a non-Lightning Experience app. User Interface API even provides endpoints to perform CRUD operations on the data presented with the layout allowing users to edit, update, and delete data. The common use case for User Interface API is to replicate all or part of the Salesforce user interface within a custom mobile or web app. I do not recommend using User Interface API for any data extraction or data uploads because User Interface APIs are contextual to the page displayed. Technical context for this option: Interface context |
Batch Apex | Developers can create Batch Apex to build complex, long-running processes that run on thousands of records on the Lightning Platform. Batch Apex operates over small batches of records, covering the selected record changes and breaking the processing down to manageable chunks. Developers use Batch Apex primarily for archiving solutions that run on a nightly basis looking for records past a certain date and adding them to an archive or build a data cleansing operation that goes through selected objects on a nightly basis and updates them if necessary, based on custom criteria. Technical context for this option: Business logic context |
Queueable Apex | Queueable Apex are programmatic actions (i.e., jobs) that can be queued for execution, along with a job ID that can be monitored for execution status. Another benefit of Queueable Apex is the ability for developers to use non-primitive data types, such as sObjects or custom Apex types. Those objects can be accessed when the job executes, which cannot be used in asynchronous Apex (i.e., when using future methods in an Apex class). Queueable Apex also allows for chaining multiple jobs by chaining one job to another job by starting a second job from a running job. Chaining jobs is useful if you need to do some processing that depends on another process to have run first. Technical context for this option: Data context and/or business logic context |
Scheduled Apex | Scheduled Apex jobs can be used to invoke Apex classes to run asynchronously at specific times using the scheduling interface. Technical context for this option: Data context and/or business logic context |
SOQL/SOSL | Similar to the industry-known Structured Query Language (SQL). Salesforce Object Query Language (SOQL) is the query language that can only be used within Salesforce to query any/all data within Salesforce. “Salesforce Object Search Language” (SOSL) is a search language that can be used within Salesforce to perform a text-based search for data within your Salesforce org. Technical context for this option: Data context |
Order of Execution Within Salesforce
It is one thing to choose a Salesforce declarative or programmatic option based on the technical context, but it is also important to understand the order in which Salesforce executes each option. Chapter 1 talked briefly about the client-side execution vs. server-side execution in Salesforce and how the Apex runtime engine processes user requests.
Order of Execution in Salesforce
- 1.
JavaScript Validation: Dependent picklist field validation will run on the browser side and will be enforced only if there are any depended fields configured for the record on the transaction.
- 2.
DML Statement: The DML statement will start.
- 3.
Record Load: The original record is loaded from Salesforce; this will cross-check in both the existing and new records.
- 4.
Record Overwrite: The new values are overwritten in the old record.
- 5.
System Validation (first-run): Validations performed by system to enforce the integrity of field types (e.g. number fields do not have special characters), page layouts and the uniqueness of indexed fields such as external Id’s.
- 6.
Validation Rules (first-run): User-defined validation rules run if multiline items were created, such as quote line items and opportunity line items.
- 7.
Before Triggers: Before-save flows are executed. Before triggers are executed; usually, before triggers are used to perform logic in the records that are being processed. Triggers run in bulk mode with up to 200 records per transaction.
- 8.
System Validation (second-run): System validations will be performed using layout rules, required fields, field format rules, and foreign keys.
- 9.
Validation Rules (second-run): Custom validation rules are enforced in this step; note that changes done in the before trigger will affect the result of the validation rules .
- 10.
Duplicate Rules: Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.
- 11.
Save Record: Saves the record to the database but doesn’t commit yet.
- 12.
After Trigger: After triggers are executed; usually, after triggers are used to perform login in other records besides the ones being processed. Triggers run in bulk mode with up to 200 records per transaction.
- 13.
Assignment Rules: Assignment rules are triggered.
- 14.
Auto-Response Rules: Auto-response rules are executed.
- 15.
Workflow Rules: Workflow rules are triggered. If there is an update, the following actions will run again: before-update triggers, standard validations, and after-update triggers .
- 16.
Execute Flows: Flows are executed; if the flow performs a DML action, the record will go through the save procedure again.
- 17.
Escalation Rules: Escalation rules run.
- 18.Entitlement Rules: Entitlement rules run.
- a.
If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations, and updates the roll-up summary field in the parent record. The parent record goes through the save procedure.
- b.
If the parent record is updated and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations, and updates the roll-up summary field in the grandparent record. The grandparent record goes through the save procedure.
- 19.
Criteria-Based Sharing: Criteria-based sharing is evaluated and calculated.
- 20.
Commit DML: The record is committed into the database .
- 21.
Post-Commit Operations: Post-commit operations are triggered (send emails).
Salesforce AppExchange
AppExchange by Salesforce is a storefront that offers apps, bolt solutions, flow solutions, Lightning data, and components that can be installed into a given Salesforce instance to accelerate the time to market for small enhancements to full applications.
AppExchange makes it easy to improve the Salesforce software. Apps provide turnkey solutions that can be installed as managed or unmanaged packages. A managed package is created by an Independent Software Vendor (ISV) and is installed as a locked package and updated by the ISV. The application can be changed, and the update is pushed to your instance automatically. An unmanaged package is also installed from AppExchange, but is unlocked and can be modified by users in the instance. Updates are not pushed automatically, as the solution is open to changes, some of which may not be supported by the solution. The managed package is considered a first-generation managed package (1GP). As you might expect, Salesforce has introduced a second-generation managed package (2GP) that provides a new way to build modular applications managed using your version control system.10
With 2GP, Salesforce offers a packaging designed for internal business apps called the unlocked package. The unlocked package uses a version control system to create, distribute, and deliver source-driven development.
Faster deployment
Better customer service
Available documentation
Regular updates
Quality assurance and security
Bolt solutions allow the ISV or internal developer to create solutions quickly using declarative capabilities within Salesforce and package them to be reused. This design can save organizations time and money. Bolt solutions can also combine any of the following solutions: community templates, flow categories, and custom apps.
Flow solutions take advantage of no code Lightning Flows that can package predefined business processes. Flow solutions are similar to bolt solutions, as they can be combined to enhance existing apps.
Lightning data are packages that are used to enhance and add data to your Salesforce data. The data is offered by third-party companies such as Dun & Bradstreet. The solution can fill out missing fields or add missing associated records such as email addresses and account contacts.
Components are available Lightning components (both Aura and LWC) that can be loaded and used to enhance your Lightning experience, process, and integrations. The components are loaded for use with the App Builder Canvas app.
No matter the solution you are using, AppExchange is an option that should be considered. Many of the solutions are free or very low cost and can add functionality quickly.
Considerations for Using Off-Platform Systems Instead of Salesforce
Do you have large data volumes (LDVs)? Data volumes that are in the tens to hundreds of million records can cause significant performance issues.
Are you looking for an off-line backup or archival solution? By default, these solutions should be off-platform.
Do you have unstructured data or need a Big Data solution? Salesforce has a solution, but often, a Big Data application is better off-platform.
Do you need two-phase commit transaction processing where you need to ensure the atomicity property of the transaction? This means that a transaction updates two or more independent databases, and all need to be confirmed before the transaction can complete for any of the databases. Salesforce does not support this requirement natively.
Does your solution need to support an external ERP or financial system? These solutions are often off-platform and require integration. They are not candidates for solutions in Salesforce.
Do you need to process payments? The payment gateway and the payment processing application are external and are not candidates for solutions in Salesforce.
Do you have a highly branded web application? Often, it is better to keep the solution off-platform.
Do you have legacy applications or specialized solutions? The investment to move these applications into Salesforce may not make sense.
Does the organization have a cloud-based infrastructure environment such as AWS or Azure? It is advisable to use an application rationalization framework to identify candidates for Salesforce. Look at TCO, business value and fit, business need, and time to market.
Salesforce Org Strategy Considerations
Risk of exceeding governor limits within a single org can be mitigated by having multiple orgs, as each org will have its own set of governor limits.
Logical separation of data and business functions to support regulatory and compliance requirements or business complexity.
Risk of large data volumes within a single org can degrade the system performance.
Organization-wide default settings related to object-level security and role hierarchy can be different and uniquely set for each org in multiple orgs.
Licensing needs to be considered separately for each org; common users in multiple orgs will need to have multiple licenses with respect to each org.
Deploying a common set of configurations or code across multiple orgs cannot be done within an org-based development approach since sandboxes related to each org can only be used to deploy within the same org.
Single-Org vs. Multi-org Strategy
Organization Strategy | Pros | Cons |
|---|---|---|
Single-org | Cross-business unit collaboration. | Org complexity could become a barrier to progress. |
Salesforce Chatter shared in the organization. | Potential to hit specific org limits, such as number of custom tabs, objects, and code lines. | |
Aligned processes, reports, dashboards, and security – consolidated customization. | Org-wide settings could become difficult to govern and manage. | |
Ability to share data. | Time to market and innovate could be impacted by the number of teams rolling out new functionality. | |
Unified reporting | More teams updating shared configuration and code means more regression testing is needed as complexity increases over time. | |
Single login to access multiple business functions. | Fewer sandbox environments reduce testing capabilities. | |
360 view from a central point of view – overall reports possible. | Local administration is difficult. | |
Interfaces are easier to maintain. | Can violate adherence to industry compliance standards such as EU GDPR privacy laws requiring logical separation of data and user visibility. | |
Multi-org | Logical separation of data. | Harder to get a clear global definition of processes and data. |
Reduced risk of exceeding org limits. | Less reuse of configuration and code. | |
Org-wide settings are easier to be governed and managed since Lower data volumes within a single Org – potentially improves performance. | Solutions for shared common business requirements need to be deployed into multiple orgs. | |
Improved time to market and freedom to innovate. | Inferior collaboration across business units (no shared Chatter). | |
Fewer teams impacted by shared updates. | Duplicated administration functions required. | |
Reduced complexity within a single org. | Increased complexity for single sign-on. | |
More sandbox environments mean more testing capabilities. | Merging/splitting orgs and changing integration endpoints is very difficult. | |
Local administration and customization possible. | The administration is extensive for configurations that cannot be deployed by automated processes (deployment strategy needed). |
Independent Multi-org Strategy : In this type of setup, each Salesforce org is set up independently with no connection or links maintained with any other Salesforce org.
Master-Child Multi-org Strategy : In this type of setup, a master organization is treated as the centralized parent org with all other Salesforce organizations being connected to this parent org using the Salesforce to Salesforce11 feature that allows seamless integration and exchange of data among the connected Salesforce organizations. The master Salesforce org manages the master records for all accounts and contacts and distributes a subset of all related data to each linked Salesforce org that acts as the child organization to the master org.
Decentralized Multi-org Strategy : In this type of setup, each Salesforce org is connected to all other coexisting Salesforce organizations, without any one Salesforce org acting as the master. Each Salesforce org maintains the master copy of all records and data stored within its own org, and each organization is directly linked to other Salesforce organizations using the Salesforce to Salesforce feature that allows seamless integration and exchange of data among the connected Salesforce orgs.
You should certainly choose and identify the ideal org strategy within your system landscape so that the stakeholders can evaluate the context, value, and considerations for managing a single org of Salesforce vs. a multi-org strategy.
Chapter Summary
The five distinct license types within Salesforce
The six types of user licenses
Comparisons of the Salesforce community products
Considerations and limitations of platform licenses vs. CRM licenses
Considerations for common declarative and programmatic design choices for application design
Order of execution of all events within Salesforce
Salesforce AppExchange and the various types of components available on AppExchange
The nine considerations for using off-platform systems instead of Salesforce
Key considerations for using a single-org vs. multi-org strategy
Three common approaches to implement a multi-org strategy