The knowledge and skills that app builders are expected to demonstrate in order to pass the Salesforce Fundamentals section of the Certified Platform App Builder exam are as follows:

• Describe the capabilities of the core CRM objects in the Salesforce schema.
• Given a scenario, identify the boundaries of declarative customization and the use cases for programmatic customization.
• Identify common scenarios for extending an org using AppExchange.

  Reference: Salesforce Certified Platform App Builder Exam Guide

  This guide is published by Salesforce and can be referenced at https://trailhead.salesforce.com/help?article=Salesforce-Certified-Platform-App-Builder-Exam-Guide.

In the Salesforce Certified Platform App Builder Exam Guide the total number of questions is given as well as, a percentage break-down for each of the objectives, and an indication of the number of features/functions that can be expected in each of the objectives.

By analyzing these objectives, percentages, and question counts, we can determine the likely number of questions that will appear in the exam and for the Salesforce Fundamentals objective.

Salesforce Fundamentals: Total number of exam questions

There are likely to be 5 questions in total. This is calculated as 8% of the 60 total exam questions, which is 4.8 or 5 questions.

Using these figures for the Salesforce Fundamentals objective and the number of items that are likely to be assessed, we can determine that there would be 1-2 questions for each of the following concepts:

• The capabilities of the core CRM objects in the Salesforce schema
• Where the boundaries lie between declarative and programmatic customization
• How and when to use AppExchange

Now, let's look at what is meant by the Salesforce Lightning Platform.

Now that we know about the skills and knowledge that are expected for passing the Certified Platform App Builder exam, let's seek to answer the question what is the Salesforce Lightning Platform? The Salesforce Lightning Platform is a cloud service that uses the Software-as-a-Service (SaaS) licensing and delivery model, and it has continued to evolve since its incarnation in 1999.

When it was first launched, the Salesforce Lightning Platform delivered services to empower Salesforce management within the limited realm of a customer relationship management (CRM) application. However, Salesforce disrupted the traditional software vendors of the day by introducing upgradeable, scaleable, feature-rich solutions for managing the sales process from lead to won deal and beyond within their initial CRM products.

The difference between the Salesforce Lightning Platform and other CRM software at the time was that not only did the CRM application contain standard CRM features but the features and functionality were continually enhanced and upgraded without the need for customers to install updates themselves. This ability of the platform to provide regular updates was achieved due to the multitenancy architecture of the Salesforce Lightning Platform. Let's discuss more about multitenancy.

Sharing system resources by using multitenancy

The multitenency architecture of the Lightning Platform provides a single instance of a database that is accessed by multiple organizations, or tenants. This is similar to multiple tenants sharing resources in an apartment block such as water, electricity, gas, and so on.

Multitenency allows economics of scale where the resource and maintenance overheads are shared by all those that are being serviced. Within the multitenancy architecture, when used for a single instance of the Lightning Platform database, all of the data is managed for all customers and is stored in a single database schema. This allows Salesforce to update only one application and have the changes distributed for all customers, resulting in three major functional releases per year for spring, summer, and winter releases.

The single database schema, however, does not only store customers' data but it also stores the mechanisms for determining how the data is secured and how it is functionally used by each of the separate customers. The Lightning Platform ultimately controls the data storage and organization functionality for each customer to enable the customization of the core processes, and this is achieved by the use of metadata.

Building business solutions within a metadata-driven development model

If you are not familiar with the Salesforce Lightning Platform, you could be forgiven for thinking that the architecture for the application simply uses a set of web pages connected to data storage (such as a relationship database) using a common industry database connection. This, however, is not the reality, and instead, the Salesforce Lightning Platform uses metadata to expose a system built from an abstracted database with associated user interfaces.

Salesforce realized at the outset when designing its platform that businesses have unique business processes and challenges, and two organizations are rarely the same. As a result, Salesforce developed the Lightning Platform with a metadata-driven development model in mind so that it could be customized by its customers.

The features and functionalities of any given app for any given customer within the Lightning Platform are defined by the collection of metadata for that app, partitioned and stored securely in the core database.

The benefits of the metadata-driven development model mean app builders, developers, and system administrators don't need to worry about connecting to data or spending time analyzing data access scalability or performane; instead, they can concentrate on building business solutions. Hence, application build productivity is increased. More importantly, the metadata-driven development approach provides app builders with the facilities to build apps, pages, and business processes without any code development.

Since the platform is multitenant and paid for by a SaaS licensing and delivery model, there has to be some kind of limit on the amount of metadata, data storage, and usage, otherwise one customer might use far too much of the available resources at the expense of another customer. As a result, there are some limits that are fixed and cannot be amended and others that are able to be increased for an additional cost. Hence, organizations can choose to pay for an edition that will offer them the most appropriate set of features for the price they are willing to pay. There are the following editions: Essentials, Professional, Enterprise, and Unlimited.

Within the Lightning Platform, data such as files and records can be stored. The record storage mechanism uses structures known as objects. Let's look at the features and capabilities of Salesforce objects.

Looking at the features and capabilities of Salesforce objects

Objects in the Salesforce Lightning Platform are used for the storage of record data and also have built-in user interface mechanisms to enable users to interact with record data. Salesforce objects are key concepts that you will need to understand as an app builder and will most likely be included in the exam.

There are standard objects and custom objects in the Lightning Platform. Standard objects are provided out of the box by Salesforce and will be present when you first sign up and create your instance. Custom objects are objects that you can create to extend the standard functionality, where the need for a specific type of record data or process is not catered for by the provided set of objects.

Standard and custom objects are similar in nature to a database table and have properties that include fields, records, relationships, and tabs. Fields are a similar concept to a database column. Records are a similar concept to a database row. Relationships enable the association of data with other objects. Tabs are the user-interface elements used to display the underlying object data.

Salesforce provides standard objects known as the core CRM objects with which to store data records and enable your organization's business processes for customer relationship management. When you initially sign up for a new Salesforce instance, standard objects such as Lead, Account, Contact, and Opportunity are provided out of the box. Let's now learn about the standard Salesforce CRM objects.

At the core of the Salesforce Lightning Platform is the ability to create CRM solutions that manage the sales process with solutions for marketing, sales, and service. The CRM application has evolved over the years since its first introduction in 1999; however, at the heart of the platform are features and functionality that help businesses, large and small, to manage the sales process from lead to won deal and beyond.

Let's look at the standard Salesforce CRM objects in the Salesforce CRM. At this point, I'd like to invite you to log in to Salesforce and take a look at the home page, click on the setup link, and generally have a click around the CRM objects. If you do not have access to Salesforce or wish to create a new Salesforce instance, you can sign up for a free Developer Edition account.

Log in to your Salesforce instance or create a free Salesforce Developer Edition account by carrying out the following steps:

1. Navigate to the web URL https://developer.salesforce.com/.
2. Click on the Sign Up button on the page.
3. Enter your details into the Sign Up form.
4. Click on the Sign me up button.
5. You should then receive a Welcome to Salesforce email.
6. Finally, click on the Verify Account link in the Welcome to Salesforce email and you will have created your new Salesforce Developer Edition account.

Knowing about the standard Salesforce CRM objects and understanding where customization is required is key to the knowledge required for an app builder. In the Salesforce Certified Platform App Builder Exam Guide, the total number of questions that will appear for standard Salesforce CRM objects as part of the Salesforce Fundamentals objective is as follows:

Salesforce Fundamentals: "Describe the capabilities of the core CRM objects in the Salesforce schema"

There are likely to be 1 or 2 questions in total. This is calculated as 8% of the 60 total exam questions, which is 4.8 or 5 questions and 3 features/functions in the Salesforce Fundamentals objective.

At the core of the Salesforce Lightning Platform is the ability to easily deliver solutions for CRM. Standard objects and functionality go hand in hand. You can also create custom objects and customize functionality, which will be covered in Chapter 2, Designing and Building a Data Model.

There is lots to know about the core functionality that makes up the core objects and there is functionality that is in-built within processes, such as lead conversion. The capabilities of the Salesforce CRM enable the processing of marketing campaigns and leads through to accounts, contacts, and opportunities, and finally onto service cases, as shown in the following diagram:

Figure 1.1 – Core object and business flow diagram

Let's look at the following feature areas and at the core concepts that are essential to understand before attempting to sit the exam: campaign and lead management; account, opportunity, and contact management; and case management.

The core features of marketing within the Salesforce CRM enable marketing professionals to manage and automate marketing campaigns in conjunction with lead development alongside the sales team. Within the marketing features, the following core CRM objects and capabilities are provided out of the box:

• The Campaign object
• The Lead object
• Lead conversion

We will first look at the features and capabilities of the Campaign object.

The Campaign object

The Campaign object provides features and functionality for the management of campaigns. Campaigns are marketing initiatives to target prospects and existing customers and include activities such as traditional conference and trade shows, print advertising, and direct mailings. Campaigns are also in the form of digital media, online advertising, and email targeting. The Campaign object facilitates the features and functions for campaign management and has links to the lead, as well as any opportunities that have been influenced by the campaign. The campaign management feature in the Salesforce CRM allows marketing users to manage and track outbound marketing activities. These can be direct mail, roadshows, online or print advertising, email, or other types of marketing initiatives.

The essential concepts, features, and built-in processes for the Campaign object include the following:

• Marketing User checkbox: Users must have Marketing User checked on their user record to use campaigns:
• Campaign Members: Contacts and leads can be associated with campaigns as campaign members.
• Campaign Influence: This is used to measure the effectiveness of campaigns by determining how the associated leads and opportunities have resulted in sales.
• Campaign Effectiveness: The effectiveness of a campaign can be analyzed using either the statistics on the campaign record or by running campaign reports. Standard reports are provided out of the box to analyze the effectiveness of the campaign, such as the Campaign ROI Analysis Report, the Campaign Revenue Report, and so on.

Let's look at the features and capabilities of the Lead object.

The Lead object

The Lead object provides the business with processes and structure for lead management. Leads are prospects or potential opportunities and are accessed in the Salesforce CRM from the Leads tab. They are sources of potential deals that usually need more qualification. They may be visitors to your website who have requested information, respondents to marketing campaigns, trade show visitors, and so on.

Leads are stored and managed independently in core objects such as Account, Contact, and Opportunity records, which are covered later in this section. However, Lead records can optionally be converted into an account, contact, and (at times optionally) an opportunity. If person accounts are activated (covered later in this section) and there is no value set for the account name, then the Lead record is converted to a person account and an opportunity.

The essential concepts, features, and built-in processes for the Lead object include the following:

• Lead Process: Establishing a lead business process involves implementing the steps and field values that are to be recorded by the sales and marketing teams during the lead life cycle. The lead process allows you to specify the Lead Status for lead records.
• Web-to-Lead: This enables leads to be directly entered into your Salesforce org from a public-facing website. This feature is used to generate HTML (HyperText Markup Language) code, which can then be incorporated into the required web page.
• Web-to-Lead Auto-Response Rules: Auto-response rules provide a mechanism to automatically respond to an individual after they have filled out a web lead form. The auto-response rules can contain logic to determine which email template and what content to send, which you can customize.
• Lead Queue: Queues can be thought of as a storage location to group records together. For leads, the lead queue is usually organized by geographic region or business function. Lead records remain in the queue until they are assigned or have been accepted by a user. Users who have been included as part of the queue can access and accept the records by clicking on a button labeled Accept.
• Lead Assignment Rules: Lead assignment rules determine how leads are automatically assigned to users or a queue. They contain rule entries, which are predefined business rules that determine the lead routing. Although you can create multiple rules, only one rule can be active at any one time.

Next, we will discuss lead conversion.

Lead conversion

Lead qualification depends on your business process, which usually involves the marketing and sales teams agreeing on the lead process, and when leads are qualified, users can convert the Lead record into an Opportunity record (the Opportunity object is covered later in this section).

When Lead records are converted, certain key information within the Lead record is mapped to the Salesforce CRM objects' accounts, contacts, and optionally the Opportunity records. Users can click on the Convert button on a Lead record, which presents the Convert Lead page.

The Convert Lead page allows the following:

• Choose to either create a new Account record or choose an existing Account record.
• Choose to either create a new Contact record or choose an existing Contact record.
• Choose to either create a new Opportunity record or choose an existing Opportunity record, or with the selection of the checkbox Don't create an opportunity upon conversion to not create an Opportunity record.

If you choose the existing Account and/or Contact records, only empty fields on the account and/or contact will be updated with the information from the Lead record. The fields on the existing Account and/or Contact records do not get overwritten.

Converted Lead records are set to read-only

Converted Lead records are set to read-only during lead conversion; however, as a system administrator, you can view converted Lead records. You can also provide users with permission to view and edit them, if necessary, by assigning them the View and Edit Converted Leads permission on their profile or within a permission set.

After the Lead record has been converted, the following values are set:

• The company name from the lead becomes the account name.
• The lead name from the lead becomes the contact name.
• The opportunity and contact are associated with the account.
• Any campaigns related to the lead are associated with the opportunity.

  Person accounts lead conversion

  If person accounts, which are covered later in this section, are activated and there is no value set for the company name, then the Lead record is converted to a person account and an opportunity.

The core features of sales within the Salesforce CRM enable marketing professionals to manage and automate marketing campaigns in conjunction with lead development alongside the sales team. Within the sales features, the following core CRM objects and capabilities are provided out of the box: Account or Person Account, Contact, Opportunity, and Case.

We will now look at the features and capabilities of the Account object.

The Account object

The Account object enables the management of company information for the organizations that your organization is involved with. Accounts may be considered as business accounts from a Business-to-Business (B2B) perspective and are usually the company records stored within the Salesforce CRM application.

Account records are also the primary mechanism used within the Salesforce CRM for the organization of records. Accounts are used within the record sharing and ownership hierarchy and are the parent object for other standard objects, such as contacts, opportunities, and cases. This is important to know when considering what permission security settings are needed to allow users to access record information. In this respect, record-level security controls and the sharing model for these child objects may be set as Controlled by Parent, which means they inherit their permission from the Account settings. This will be covered in more detail in Chapter 4, Securing Access to Data.

The essential concepts, features, and built-in processes for the standard Account object include the following:

• Account Hierarchy: By associating an Account record in the standard Parent Account field, a hierarchy of accounts can be established.
• View Account Hierarchy: This feature enables users to see the full association of parent and child Account records within the account hierarchy.
• Account Teams: This feature enables the granting of access to Account records for specific users who work on the same account. The feature can be used by users that are the owner of the Account record (or users that are above them in the role hierarchy and system administrators). This feature is disabled by default and there can only be one Account team but with multiple roles.
• Account Merge: This feature enables up to three Account records to be merged together in a wizard-style dialog. B2B accounts and Business-to-Consumer (B2C) person accounts cannot be merged with each other.

Salesforce provides another variety of account called a person account, which allows organizations with a B2C business model to manage relationships with individuals.

Let's look at the capabilities of the Person Account object.

The Person Account object

The Person Account object is used in the context of a B2C business model and provides a very similar set of features and fields to the standard Account object; however, Person Accounts have some differences.

Person Account object architecture

The Person Account object comprises both an Account object and a Contact object. There is an increased data storage requirement to house both these records per person.

The essential concepts, features, and built-in processes for the Person Account object include the following:

• No Account Hierarchy: There is no Parent Account field for person accounts, hence the hierarchy of accounts can be established and viewed.
• Account Merge: This feature enables up to three account records to be merged together in a wizard-style dialog. B2B accounts and B2C person accounts cannot be merged with each other.

We will now look at the capabilities of the Contact object.

The Contact object

The Contact object enables the management of contact information. Contacts are the individuals that your users want to keep in touch with. For the sales team, this is likely to be people such as purchasers and key decision-makers. For the marketing team, this may include the CEOs and CFOs and other influencers. For support, contacts could be any of the users of the product or service that your organization provides.

The essential concepts, features, and built-in processes for the Contact object include the following:

• Contacts to multiple accounts
• Contact hierarchy
• Private contacts
• Merge contacts

Let's look at the features and capabilities of the Opportunity object.

The Opportunity object

The Opportunity object enables the management of sales information. An Opportunity represents a financial transaction, deal, or a pledge between a customer or benefactor and a company or charity. For nonprofits, this could be donations and for business enterprises, this could be products and services.

Opportunity records are processed using a business sales process with predefined sales stages that typically advance to a final stage of either closed/lost or closed/won, where a closed/won opportunity represents a successful sale or paid donation. Opportunity records can either be generated from lead conversion or can be entered manually by the sales team.

The essential concepts, features, and built-in processes for the Opportunity object include the following:

• Sales team
• Opportunity splits
• Forecasting

Within the service features, the following Case object and capabilities are provided out of the box.

The Case object

The Case object enables the management of customer issues, feedback, incidents, or questions associated with the products and services that your organization is involved with. Organizations can use Cases to automate and manage requests for service and support by existing customers such as complaints, requests to return faulty merchandise, or requests from prospective contacts to provide information about products and services.

Case records can be manually entered from the Cases tab by users after, say, a phone call or email to or from a customer, and there are various features that support the automation of Cases within the Salesforce CRM and are associated with Contact records and/or Account records.

Case records can be created manually by users accessing the Cases tab, along with automated methods that allow external individuals to create Cases using web forms or email.

The essential concepts, features, and built-in processes for the Case object include the following:

• Web-to-Case: This feature enables customers to submit Case records online.
• Email-to-Case: This feature enables Case records to be automatically created when an email is sent to pre-configured email addresses.
• Auto-Response Rules: This feature allows the sending of an email to respond when Cases have been received in the Salesforce Lightning Platform.
• Case Queues: Cases are either manually assigned or they can be automatically assigned to Case queues (or to users) using assignment rules.
• Assignment Rules: Only one case assignment rule can be active at any one time, and each rule can contain multiple criteria up to a maximum of 25 criteria. Cases can be automatically assigned to users or queues using assignment rules.
• Escalation Rules: Automatically escalates unresolved Cases after a specified period of time.

So far, we have looked at the standard process automation that is available out of the box for standard objects. However, as briefly mentioned earlier in this chapter, Salesforce provides options to enhance the business process and modify the CRM application instance to meet specific business requirements for your organization.

We will now look at the features in the Salesforce Lightning Platform that enable app builders to customize the platform and build custom objects.

Understanding when the standard Salesforce CRM processes and out of the box features are not appropriate or not sufficient to meet given requirements and require customization is key to the knowledge required for an app builder.

In the Salesforce Certified Platform App Builder Exam Guide, the total number of questions that will appear for customizing the Lightning Platform as part of the Salesforce Fundamentals objective is as follows:

Salesforce Fundamentals: "Given a scenario, identify the boundaries of declarative customization and the use cases for programmatic customization"

There are likely to be 1 or 2 questions in total. This is calculated as 8% of the 60 total exam questions, which is 4.8 or 5 questions and 3 features/functions in the Salesforce Fundamentals objective.

We will now look at the following concepts and considerations for customizing the Lightning Platform:

• Programmatic customization
• Declarative customization
• Process Builder action types
• The Workflow and Approvals action types
• General use cases for programmatic customization

Let's look at the features and capabilities for programmatic customization in the Lightning Platform.

Programmatic customization

The good news, if you do not enjoy being tested on coding skills, is that the Salesforce Certified Platform App Builder exam contains no questions on how to write code using programmatic customization.

While you will not be expected to know how to program or be given any questions on writing code, you are expected to have an understanding of how code can be used in the Salesforce Lightning Platform. You must have an awareness of what code options exist in the Salesforce Lightning Platform, and this is particularly important when app builders are faced with a need to build or implement the most appropriate solution.

The programmatic options for customizing the Salesforce Lightning Platform include the following:

• Apex Code: Apex is an object-oriented programming language that executes on the Salesforce Lightning Platform. Similar to Java, the Apex programming language allows the building of functionality that executes transaction control statements within the server.
• Apex Triggers: Apex triggers are used to create custom actions that execute before or after events such as record creation, record update, and record deletes, and are used when there is no user input.
• Visualforce Pages: Visualforce pages comprise sets of tags that connect to the server and render back to the web user interface. The tags are associated with standard or custom controllers that are used to connect to the database.
• Lightning Components: Lightning components are available in two programming models. Firstly, there is the Aura Components programming model, and secondly, there is Lightning Web Components (LWC), which uses a lightweight framework with JavaScript and HTML.

The advantages of using programmatic customization include the following:

• Flexibility
• Reusability
• User interface complexity
• Integration

While there are benefits, there are also disadvantages, such as the following:

• Additional testing requirements
• Higher development costs
• A potential lack of scalability
• Less responsiveness to change
• Additional risk when deploying changes
• A lack of availability of developer skills

Having outlined the options for code and the advantages and disadvantages, we will now outline the options for declarative customization.

Declarative customization

There are several terms you may be aware of that are used to describe declarative customization. Some of those terms are Clicks not Code, Point and Click, Drag and Drop, Click v Code, and No Code Development.

What these terms mean with respect to the Salesforce Lightning Platform is that they allow solutions to be built by individuals without the need to write code.

Let's look at the options for building apps using declarative development. We will look in far more detail at building solutions using declarative development tools in Chapter 7, Building Business Process Automation.

The declarative options for customizing the Salesforce Lightning Platform include the following:

• Process Builder: Process Builder is a workflow automation tool that allows you to automate business processes and uses a user-friendly visual interface with point-and-click features. The tool supports the building of multiple rules with associated criteria and actions in a single process where actions are fired when new or updated records meet the specified criteria. Process Builder starts when either a record is created or edited, Process Builder is called by another process, or a platform event message is fired.
• Flow: Flow is a workflow automation tool that allows you to automate business process screen wizards or complex background processes that use extensive branching logic.

  Like Process Builder, flows are created using Flow Builder, a user-friendly visual interface with point-and-click features. Flows can be either screen flows with a user interface or autolaunched flows that do not have a screen.

• Approvals: Approval processes allow the configuration of steps that are used to approve or reject records that have been submitted for approval. Approval processes include entry criteria and designated uses that must be met to allow approval during the steps. In addition, approval processes allow the creation of actions that are triggered as a record is submitted, approved, rejected, or recalled.
• Workflow: Workflow rules initiate workflow actions when specified conditions (or criteria) have been met. Workflow actions can be set to execute immediately or can be set using the time-dependent feature that results in the workflow actions being executed at a future date.

  Automation and editions

  At the time of writing, Process Builder and Flow are available in the following editions: Essentials, Professional, Enterprise, Performance, Unlimited, and Developer. Approvals and Workflow are available in the following editions: Enterprise, Performance, Unlimited, and Developer.

  Reference: https://help.salesforce.com/articleView?id=process_which_tool.htm

Now let's look at the type of actions that can be performed in Process Builder.

Process Builder action types

In Process Builder, the following actions types can be performed:

• Apex: Apex actions invoke an Apex class with an invocable method.
• Create a Record: Creates a record – actions allow you to create a record of any supported type.
• Email Alerts: Email alert actions use an email template that is used to populate the email details that are sent to specified recipients that can be either Salesforce CRM users or external email recipients.
• Flows: Flow actions enable the triggering of an auto-launched flow.
• Post to Chatter: This action enables the creation of a Chatter Post.
• Processes: These actions enable the invocation of a different process.
• Quick Actions: Quick actions are used to invoke an action.
• Quip: This action initiates a Quip integration. Quip for Salesforce provides a collaborative document and chat integration within Salesforce. Quip actions are available if you have Quip for Salesforce integration.
• Send Custom Notifications: This action sends custom notifications, which are used to notify users when important events occur.
• Submit for Approval: This action enables the automatic submission of an approval process.
• Update Records: This action enables the update of any related record.

Now let's look at the type of actions that can be carried out in flows.

Flow action types

The process automation actions that can be configured in Flow are separated into two areas: namely Flow Elements and Flow Core Actions. Flow Elements allow the following types of automation to be carried out:

• Apex Action: Apex actions invoke an Apex class with an invocable method.
• Subflow: This action enables the triggering of another flow.
• Create Records: This action enables the creation of either one or multiple records.
• Get Records: This action gets records based on specified criteria.
• Delete Records: This action deletes records using the record ID.
• Update Records: This action enables the update of any related record.
• Email Alert: Email alert actions use an email template that is used to populate the email details to be sent to specified recipients, which can be either Salesforce CRM users or external email recipients.
• Core Action: There are many types of core actions, such as Email Alerts, Submit for Approval, and so on, and these are listed in the next section.

Nested within the Flow Elements Flow Core Action options, the following types of actions can be performed:

• Update Records: This action enables the update of any related record.
• Activate Session-Based Permission Set: This action activates a session-based permission set for the user that is running the flow.
• Deactivate Session-Based Permission Set: This action deactivates a session-based permission set for the user that is running the flow.
• Post to Chatter: This action enables the creation of a Chatter Post.
• Action: Quick actions are used to invoke an action.
• Send Custom Notification: This action sends custom notifications, which are used to notify users when important events occur.
• Email Alerts: This action sends an email using a subject, body, and email recipients.
• Submit for Approval: This action enables the automatic submission of an approval process.

Now let's look at the type of actions that can be carried out in Workflow and approvals.

Workflow and approval action types

There are different Workflow and approval action types, which are listed here:

• Email Alerts: Email alerts actions use an email template that is used to populate the email details to be sent to specified recipients, which can be either Salesforce CRM users or external email recipients.
• Field Updates: Field update actions allow you to specify a field for update and set a new value for it. The field's update action depends on the data type of the field, where you can choose to apply a specific value, clear the field, or calculate a value according to criteria or a derived formula that you can specify.
• Tasks: Task actions enable the assignment of tasks to a user that you can specify. You would also specify the Subject, Status, Priority, and Due Date of the task. Tasks can be assigned on their own, but you can also combine them with an email alert to inform the user.
• Send Action: Send actions are used to automatically send email messages at the end of an approval process.
• Outbound Messages: This an action that can be activated by both workflows and approvals, which sends information to a web URL endpoint. The outbound message contains the data in specified fields in what is known as a SOAP message to the endpoint.

Having previously looked at the advantages and disadvantages of building solutions using code, we will now consider one of the often-difficult choices when working with the Lightning Platform, namely, when to use programmatic solutions and when to use declarative development.

In reality, in most Salesforce instances – certainly ones that have been customized over a reasonable period of time – there is no distinct separation between ones customized declaratively and ones that contain programmatic solutions. There tends to be a mix of both methods of customization both at the org level and also at the solution level.

We will now look at how we can assess the most appropriate method of customization for the types of requirements that app builders may encounter. Let's now identify the boundaries of declarative customization and the general use cases for programmatic customization.

General use cases for programmatic customization

As we learned previously in this chapter, Salesforce pioneered the ability to provide a platform that can be developed by using code and non-coded mechanisms. The platform allows an underlying architecture that supports business processing and data storage – metadata key building blocks needed are to build applications.

Although there are no hard and fast rules on when to use code, the specific use case and the resources available help to determine the best approach, and in other situations, there are some solutions that must be built with code as this is the only option.

Here are some general use cases for choosing programmatic solutions:

• Integration using the API to connect with other systems
• When highly complex user interfaces are required
• When large data volumes need to be batched and processed in the background
• When the out-of-the-box standard object features need to be extended
• When the out-of-the-box automation tools do not have the necessary actions

Here are some specific use cases where out-of-the-box automation tools lack the capability and that require a programmatic solution:

• When records need to be undeleted
• When multiple types of records need to be simultaneously created or updated
• When adding Apex to flows or Process Builder
• When adding Lightning components to flows

Often, adding Lightning components to flows or including Apex in Process Builder offers a far better solution than attempting to build a solution either entirely in code or entirely using declarative tools.

Avoid building complex flows

It is often better to avoid building complex flows that push the boundaries of the Flow Builder tool and are difficult to manage, and to instead use a programmatic solution.

Programmatic solutions such as Lightning components and apps can be sourced on Salesforce AppExchange, which we will now explore.

Launched in 2006, Salesforce AppExchange is a business cloud marketplace provided by Salesforce and is integrated within the Salesforce Lightning Platform. Access to AppExchange can be gained via a website hosted by Salesforce and also from within the Salesforce CRM application.

There is an expectation that app builders will be familiar with what is available on AppExchange and what the use cases are for choosing to install solutions in an org from AppExchange, as noted in the Salesforce Certified Platform App Builder Exam Guide:

Salesforce Fundamentals: "Identify common scenarios for extending an org using the AppExchange"

There are likely to be 1 or 2 questions in total. This is calculated as 8% of the 60 total exam questions, which is 4.8 or 5 questions and 3 features/functions in the Salesforce Fundamentals objective.

There is a variety of solutions and services that are available on AppExchange that serve to extend the core functionality and features within Salesforce.

Note

Salesforce AppExchange can be accessed using the following URL: https://appexchange.salesforce.com/.

The solutions and services listed on AppExchange are provided by the Salesforce community of third-party developers and system integrators, as well as from Salesforce, and include Apps, Components, Bolt Solutions, Lightning Data, Flow Solutions, and Consultants, as shown in the following screenshot:

Figure 1.2 – Salesforce AppExchange

Solutions and services

At the time of writing, there are more than 5,000 solutions and at least 1,000 consulting services listed on the AppExchange marketplace.

Let's look at the types of solutions that are available on Salesforce AppExchange.

Apps

Apps contain prebuilt functionality that can be installed in your instance of Salesforce to extend the out-of-the-box features. An app contains items such as custom objects, tabs, code, components, and so on. Along with the listing for the app on AppExchange, there is a description of what it does, the items that it contains, and customer reviews.

In addition to the apps that are provided by the community of third-party developers and system integrators, many of the apps are provided by Salesforce through a team known as Force.com Labs. Apps are provided using various pricing models that are based on a price per user per month, a price per company per month, or are provided for free. In addition, some paid-for apps offer discounts for nonprofits.

Apps can range from highly complex, coded, feature-rich solutions with multiple screens to simple sets of dashboards or reports. Indeed, there are some instances where the full functionality of an app is not required and you just need a specific item of functionality to provide the solution, and this use case is where components can be used.

Components

Components are elements that may not function by themselves and are instead used as building blocks to build the overall solution. As an example, you may find Lightning components that automatically update records across a variety of object types given a particular scenario or automatically preset values on a record Edit page prior to saving a record, which are not out-of-the-box features in the Salesforce CRM.

There are two types of components:

• Components that are general-purpose and used for processing business logic, merging records, kicking processes, and so on
• Web components, which are designed for customizing the Lightning Experience user interface

An alternative to installing a complete app or building a custom solution with separate Lightning components is to install prebuilt declarative solutions that are available from AppExchange, called a flow solution.

Flow solutions

When building new flows, it is worth looking at AppExchange to check for existing flow solutions, which are often freely available, as it may not be appropriate to either re-invent the wheel and build or configure your own flow or install a less-flexible managed app package from AppExchange; this is where flow solutions can be used.

Flow solutions are prebuilt solutions that have been built by third-party developers and Salesforce to automate a business process, and there are two types of flow solutions:

• Flow Actions: These are standalone flows that perform a specified function and perform an action.
• Flow Templates: These are complete, end-to-end flow solutions that act as a starting point that you can save and customize to meet the business process requirements.

Another alternative to installing a complete app or building a custom solution is to work with a partner and install a prebuilt declarative solution that is available from AppExchange called a Bolt Solution.

Bolt Solutions

Bolt Solutions are solutions that have been built by third-party developers and system integrators that Salesforce customers would work with to complete their installation. The partners help customers to install and customize the solution to suit their needs. Sometimes organizations are faced with a particular industry or business standard requirement, which must be flexible, where there are industry experts at hand who can provide a declarative solution and customization guidance. In this scenario, it may not be appropriate to either re-invent the wheel and build or configure your own solution or install a less-flexible managed app package from AppExchange, and this is where Bolt Solutions can be used.

In addition to functional extensions to the Salesforce CRM, you can also find solutions that provide data enhancements for your Salesforce instances, and these are known as Lightning Data.

Lightning Data

You would use Lightning Data to make sure that the data in your Salesforce instance is in-sync and current with an external dataset from the given Lightning Data provider.

Lightning Data can be considered as special types of apps that use the services of a data connector to pull in external data to enrich the data stored in your Salesforce CRM instance. The data connector is part of an engine, called the Lightning Data Engine, that automatically connects your Salesforce instance and the third-party system and associated data feed.

Consultants

AppExchange also provides a listing of consultants that offer specialist Salesforce knowledge. Consultants are experts with proven Salesforce skills, able to provide guidance in various industry settings.

Installing an app from AppExchange

An app from the Salesforce AppExchange marketplace can be installed in your Salesforce CRM org by carrying out the following:

1. Click on the Get It Now button.
2. Select the location for the installation, where the options are to either Install in production or to Install in sandbox first!
3. Examine the package details showing what you are installing and where you are installing it.
4. Click on the checkbox labeled I have read and agree to the terms and conditions to confirm that you agree to proceed with the installation.
5. Click on the Confirm and Install! button to continue to the Salesforce login screen.
6. Log into the desired Salesforce org, ensuring that you log into your sandbox to test it before installing it in your Production org.
7. Choose the option to either install for Admins Only, for All Users, or for Specific Profiles.
8. Now click on the Install button.
9. Finally, perform any post-installation configuration.

There is some due diligence that you should be aware of and take the necessary measures for before and during the installation of a solution from AppExchange in your Salesforce instance.

AppExchange best practices

The following best practices should be applied when installing apps from the AppExchange marketplace website:

• Clarify that the specification for the app meets the requirements and assess any reviews and comments.
• Take a test drive, if available.
• Review all the components that are included in the package and be aware of any security issues concerning links and session IDs.
• Test the app in a sandbox before deploying to production.
• Try to enlist business support to own and validate the app before deploying to production.
• Consider undertaking a pilot deployment for selected users if the app is particularly complex.
• Communicate the app to the business prior to deployment and activation in production.

We present five questions to verify your knowledge of the capabilities of the core CRM objects in the Salesforce schema, where the boundaries lie between declarative and programmatic customization, and how and when to use AppExchange. The answers can be found at the end of the chapter.

Question 1 – Lead conversion

The lead conversion feature results in which of the following objects being created? (Select one)

a) Account, Contact, Opportunity, and optionally a Campaign

b) Account, Contact, and optionally an Opportunity

c) Contact, Opportunity, and optionally an Account

d) Account, Opportunity, and optionally a Contact

Question 2 – Case automation

Which of the following statements are correct about Case automation? (Select one)

a) Case escalation rules allow Cases to be automatically routed to Queues only.

b) Case assignment rules allow Cases to be automatically routed to Queues only.

c) Case assignment rules allow Cases to be automatically routed to Queues and users.

d) There can be a maximum of 25 active Case assignment rules.

Question 3 – Customizing the Lightning Platform for marketing

The marketing director in your company has asked you to identify a solution that enables the sales team to convert certain types of leads. She wants the sales team to click a Convert Lead button but there should be no option to create new Accounts or Contacts (as these records always exist for these types of lead and are entered in fields on the Lead record by her marketing team). The lead conversion process should automatically create an Opportunity record.

How can this solution be built? (Select one)

a) Build a flow that gets the lead and executes the Convert Lead Flow Element, passing the appropriate Account and Contact information.

b) Build Apex code that gets the lead and executes the convert lead functionality, passing the appropriate Account and Contact information.

c) Build a process with Process Builder that invokes the convert lead action type, passing the appropriate Account and Contact information.

d) Explain to the marketing director that it is not possible to build this in the Lightning Platform.

Question 4 – Customizing the Lightning Platform for sales

The sales director in your company has asked you to identify a solution that forces the sales team to search for Account records before they are allowed to create new Accounts. He wants his sales team to click a New button but there should be a screen on which to enter the name of the account and search before allowing the salesperson to create a new Account.

How can this solution be built? (Select two)

a) Build an Apex trigger that searches for the Account record and creates a new record if one doesn't exist.

b) Build a flow that includes a screen to find the Account using the Get Records Flow Element, a Decision, and a Create Records Flow Element.

c) Build a process with Process Builder that invokes the Find Duplicate Account action type, passing the name of the Account.

d) Build a Lightning component that presents a search dialog and uses Apex to search for the account name and show matches before allowing access to the New account option.

Question 5 – Salesforce AppExchange

Which of the following solutions can be found on Salesforce AppExchange? (Select one)

a) Apps, Bolt Templates, Web Components

b) Apps, Components, Data Templates

c) Components, Flow Actions, Apps

d) Components, Flow Templates, Lightning Bolts

Here are the answers to the five questions to verify your knowledge of the capabilities of the core CRM objects in the Salesforce schema, where the boundaries lie between declarative and programmatic customization, and how and when to use AppExchange.

Answer 1 – Lead conversion

The answer is b) Account, Contact, and optionally an Opportunity

The following are not correct:

a) Account, Contact, Opportunity, and optionally a Campaign: Leads cannot be converted to a Campaign.

c) Contact, Opportunity, and optionally an Account: The Lead record must be converted to either a new or existing Account.

d) Account, Opportunity, and optionally a Contact: The Lead record must be converted to either a new or existing Contact.

Answer 2 – Case automation

The answer is c) Case assignment rules allow Cases to be automatically routed to Queues and users.

The following are not correct:

a) Case escalation rules allow Cases to be automatically routed to Queues only: Cases cannot be routed using escalation rules.

b) Case assignment rules allow Cases to be automatically routed to Queues only: Not only Queues but users can have Cases assigned to them using Case assignment rules.

d) There can be a maximum of 25 active Case assignment rules: Only one active Case assignment rule is permitted.

Answer 3 – Customizing the Lightning Platform for marketing

The answer is b) Build Apex code that gets the lead and executes the convert lead functionality, passing the appropriate Account and Contact information.

The following are not correct:

a) Build a flow that gets the lead and executes the Convert Lead Flow Element, passing the appropriate Account and Contact information: There is no Convert Lead Flow Element in Flow.

c) Build a process with Process Builder that invokes the Convert Lead action type, passing the appropriate Account and Contact information: There is no Convert Lead action type in Process Builder.

d) Explain to the marketing director that it is not possible to build this in the Lightning Platform: Where there is no declarative solution, consider Apex as it can be used when the out-of-the-box standard object features need to be extended.

Answer 4 – Customizing the Lightning Platform for sales

One correct answer is this:

b) Build a flow that includes a screen to find the Account using the Get Records Flow Element, a Decision, and a Create Records Flow Element.

The other is this:

d) Build a Lightning component that presents a search dialog and uses Apex to search for the account name and show matches before allowing access to the New account option.

The following are not correct:

a) Build an Apex trigger that searches for the Account record and creates a new record if one doesn't exist: An Apex trigger does not allow user input and so is not appropriate for this solution.

c) Build a process with Process Builder that invokes the Find Duplicate Account action type, passing the name of the Account: There is no Find Duplicate Account action type in Process Builder.

Answer 5 – Salesforce AppExchange

The answer is c) Components, Flow Actions, Apps

The following are not correct:

a) Apps, Bolt Templates, Web Components: There is no solution named Bolt Templates.

b) Apps, Components, Data Templates: There is no solution named Data Templates.

d) Components, Flow Templates, Lightning Bolts: There is no solution named Lightning Bolts.

Understanding the capabilities of the Lightning Platform is an important objective for all app builders, and you are now equipped with knowledge of the core Salesforce CRM objects and the capabilities that exist for these core features and associated process automation.

Knowing where the capabilities and boundaries lie for the declarative building of solutions when compared with programmatic development is vital, and you have gained this knowledge to help you choose, design, and build your next solution.

In addition, we discovered how additional functionality or data is available from the AppExchange marketplace and you now know how to exploit the various options that are available for adding value to your Salesforce instance.

Finally, we posed questions to help clarify the key concepts and features that are required when tackling the Salesforce Fundamentals section of the App Builder Certification exam.

In the next chapter, Chapter 2, Designing and Building a Data Model, we will look at how to design and build a data model in the Salesforce CRM and learn about Schema Builder. We will discuss how field relationships are used and how their use affects record access. We will also look at field types and understand the impacts of changing field types.