Book Image

Salesforce Platform Developer I Certification Guide

By : Jan Vandevelde, Gunther Roskams
Book Image

Salesforce Platform Developer I Certification Guide

By: Jan Vandevelde, Gunther Roskams

Overview of this book

Salesforce Lightning Platform, used to build enterprise apps, is being increasingly adopted by admins, business analysts, consultants, architects, and especially developers. With this Salesforce certification, you'll be able to enhance your development skills and become a valuable member of your organization. This certification guide is designed to be completely aligned with the official exam study guide for the latest Salesforce Certified Platform Developer I release and includes updates from Spring '19. Starting with Salesforce fundamentals and performing data modeling and management, you’ll progress to automating logic and processes and working on user interfaces with Salesforce components. Finally, you'll learn how to work with testing frameworks, perform debugging, and deploy metadata, and get to grips with useful tips and tricks. Each chapter concludes with sample questions that are commonly found in the exam, and the book wraps up with mock tests to help you prepare for the DEV501 certification exam. By the end of the book, you’ll be ready to take the exam and earn your Salesforce Certified Platform Developer I certification.
Table of Contents (15 chapters)
Free Chapter
Section 1: Fundamentals, Data Modeling, and Management
Section 2: Logic, Process Automation, and the User Interface
Section 3: Testing, Debugging, and Exercise
Mock Tests

Common use cases for declarative customization

It's important to understand one of the biggest differentiators of Salesforce in comparison to other CRMs. Salesforce provides a lot of tools and features to maximize declarative customization (through point-and-click tools). In fact, while configuring Salesforce to suit your business needs, in 80% of cases, you will be able to solve your requirement with declarative functionality. For the remaining 20% of the use cases, you'll need some kind of programmatic development.

Becoming a certified platform developer does not mean that you solve everything with code. Customers, consultancy agencies, and Salesforce all expect a Salesforce developer to be able to use the easiest tool to achieve a solution and, therefore, most of the exam will assess whether you are able to distinguish what can be achieved through declarative configuration and what cannot be, hence, reverting to a more programmatic approach.

In Chapter 3, Declarative Automation, we'll dive deeper into ways to automate your business through declarative tools and programmatic options. For now, let's just recap the most commonly used declarative features that Salesforce offers an admin out of the box.

Objects and fields

Salesforce comes with a lot of standard objects, all of which have standard fields. Objects and fields allow you to capture data in the database.

Consider the following screenshot; here, you can compare objects and fields by having an Excel file, where you have a sheet for every object, such as accounts, contacts, quotes, and so on. In this case, you will need to keep track of multiple records and specific data:

You will also need a row for each account record, along with columns for the data that you would like to track of for the account. In Salesforce, these are represented by fields. Just like in Excel, a field can have a certain data type depending on what type of data you are tracking—that is, text, phone numbers, URLs, dates, and more.

Each object can be, but doesn't have to be, represented by a tab in Salesforce, just like creating a sheet per object in Excel. Having a tab for the object gives you the benefit of creating filtered list views of records for that type of object.

Additionally, you can extend your database to your needs; this is done by creating new custom objects yourself and creating extra custom fields on the existing standard objects and/or on your newly created custom objects to track whatever data you deem necessary. While creating a field just like in Excel, you have the choice between several data types such as Text, Text Area, Rich Text Area, Lookup relationship, Master-Detail relationship Checkbox, Picklist, Multi-Select Picklist, Phone, Email, Date, DateTime, Time, Currency, Geolocation, Formula fields, and Roll-up Summary fields.

Formula fields

A formula field is like a real-time calculation that is calculated when it is loaded or requested. It's like a formula in an Excel spreadsheet. We refer to it as loaded or requested, because it's not a calculation that appears while viewing a record in the user interface. When you request the record data, it is calculated (or recalculated) using the following methods:

  • By viewing it in the UI or in a report
  • By exporting the data through a data loader
  • By reading the data through an API call
  • By querying the data in a SOQL query

A formula field is always read-only. This means that it's not a field in which you can type or change it's value manually – it is always calculated. As a result of this, the calculation does not perform an update on the record and this can never trigger any automations. What I mean here is that you can't have something like a WFR that updates a field when that field changes without performing a manual update or other automation update of the record. You can, however, use the value of a formula field in your automation processes as a criterion or to use as a value.

I know this is somewhat confusing, so let's try to explain it using an example. Let's say that we create a formula field returning a date that is calculated, based on the creation date of a record plus 30 days, and we would like to create a task for the owner when we reach that date automatically. You could be tempted to create a Process Builder that evaluates whether TODAY() equals the date field. If it does, then create the task and, as long as that date is not equal, it's still either in the future or already past.

Now, if the record does not get updated by someone manually, or by some other automation, then nobody will touch this record and this Process Builder won't fire—this is because all automations only fire on the creation or updating of records.

Additionally, a formula field is calculated in real time when it gets requested and does not perform an update of the record. You can use your own logic in order to build the calculation that it needs to perform, and Salesforce offers a lot of functions for you to use within your formulas.

For instance, I really like the Formula Cheatsheet Salesforce that contains the most used functions. You can find it at

A formula field can return the following things:

  • Checkbox
  • Currency
  • Date
  • Datetime
  • Time
  • Number
  • Percent
  • Text

Formulas usually perform calculations with other values in the record that it resides on, but it can also use the values of parent records, or grandparent records, up to 10 levels up. However, it cannot use the values of child records. So, a common use case for a formula field is to display data from its parent. For example, let's say that we have a custom Picklist field, Region__c, on the account page and we would like to show this value on our opportunities page. Because an opportunity is directly linked to an account, we could create a formula field that renders the text using the formula TEXT (Account.Region__c).

Because a formula is always calculated in real time, this value will always represent the actual value from the Region__c field of the account on our opportunity, without manually updating all opportunities of this account whenever the Region__c field changes on the account.

A formula field that uses data from its parent, or higher up the hierarchy, is called a cross-object formula. Formulas do have some limitations that you need to be aware of; for example, you will get an error message if your formula does not comply with the following limits:

  • The maximum number of characters is 3,900.
  • The maximum formula size on saved is 4,000 bytes.

When your formula exceeds either of the aforementioned characters or byte limits, then you will receive an error message mentioning this.

Spaces, comments, and carriage returns are also included while calculating the character count.

Rollup summary fields

A rollup summary field (RUS) field is very much like a formula field in that it also performs a calculation. However, this is based on child records, and only when these child records are part of a Master-Detail relationship!

It's used to summarize a numeric value based on (filtered) child records and can perform COUNT, SUM, MIN, and MAX.

It is recalculated whenever a transaction on these child records occurs in the following ways:

  • When a new child is created
  • When one of the children gets updated
  • When a child gets deleted

You can use filters to only pull values from specific child records. For example, let's say that we have a custom Invoice__c object that is related to the account as a Master-Detail relationship. In our Invoice__c object, we have an Amount field and a Status field. We could create a RUS field in the account that represents the total amount that is overdue, which is a calculation of the SUM operation of the Amount field on all related invoices, with a filter on the Status field that is equal to Overdue.

RUS performs an update of the record they reside in and can, therefore, be used to fire off other automation tools, such as WFRs, Process Builders, and more.

Validation rules

Validation rules are used to make sure that the data entered in fields adheres to the standards you have specified for your business.; for example, making sure that phone numbers always have the same format, or that a field cannot be left blank based on the input or value of another field. If a value does not meet your validation rules, then the user will not be able to save the record. A validation rule is made of a formula or expression to check the criteria and an error message, which will be shown to the user if the values do not meet your specified criteria. The formula evaluates the data in one or more fields, and then returns either true or false. Validation rules ensure data quality in your org.

If the formula returns true, then the defined error message is displayed and the record cannot be saved. The formula can be referenced with more than one field and can also be a cross-object formula. While setting the error message, you can decide to show it next to a certain field or on top of the page.

Validation rules will run while performing operations through an API (through Data Loader, for example), on web-to-lead creations, and on web-to-case submissions. So, make sure that you design your validation rules so that they will not interfere unintentionally with these functionalities. In some scenarios, you may need to disable the validation rules while you import or update data, and then reactivate the rules afterward. Alternatively, you may exclude a specific user or profile in the validation formula so that it doesn't execute when the operation is run, as that specific user or as a user with that profile; this means that they can perform data loads without validation rules firing.


A WFR tool is one of the oldest and highest-performing automation tools. They help end users save time in their day-to-day activities. A WFR is a set of actions that need to be executed when a record is created or updated to meet specified criteria.

WFRs can be split into two main components:

  • Criteria: What must be the true record for the WFR to fire and have its associated actions to be executed
  • Actions: What to do when the record meets the criteria that was defined and which actions need to be executed

WFRs can execute the following actions (either immediately or time-based):

  • Sending an email alert
  • Performing one or more field updates
  • Sending an outbound message
  • Creating a task
  • Triggering a Lightning flow process

Consider the following screenshot:

Only orgs that were in the pilot can have calling a flow from a WFR enabled; it's not possible to enable this feature anymore, because it has now been replaced by a Process Builder action that calls a flow.

Approval processes

Sometimes, you may want to create some kind of an approval process in which records need to be approved by one or multiple other users before moving further within your business process.

A very common use case is to submit an opportunity for approval to a sales manager if a specific discount percentage or amount is exceeded.

Well, approval processes are the tools that create these types of processes. They allow you to specify an object, the criteria (or record values) that need to be evaluated before a record must be submitted for approval or not, and who needs to give their approval. After an approval or rejection, you can perform a number of automated actions, such as field updates or sending notifications. In approval processes, after submitting the record, the record is then locked. In this way, nothing can be changed until the data has been approved or rejected.

The user who is submitting the data for approval can also have the option to recall the record, which takes the record back out of the approval process.

Upon final approval or final rejection, the same actions as in WFRs can be executed, such as updating a field, sending an email, and more:

The Process Builder

In the day-to-day life of end users, a lot of repetitive work is done manually. You can minimize these manual actions (such as sending email notifications, assigning records to other users or queues, and performing record updates to certain stages and statuses) by creating automated actions through the Process Builder. The Process Builder is one of the most powerful tools that you can use to automate your business using a nice graphical interface.

The Process Builder can be kicked off in the following three ways:

  • When a record is created or updated in Salesforce
  • When a platform event occurs on the Salesforce Platform
  • When another process invokes it

Each process consists of nodes and actions, as follows:

  • In the nodes, you'll define the criteria on which a set of actions need to be executed.
  • The actions (immediate or scheduled, that is, time-based actions) need to be executed when a certain criteria node is being entered and evaluated (being true). Pay attention to the fact that only record-change processes support scheduled actions.
You can perform almost the same actions as WFR with the Process Builder, even more.

With the Process Builder, you can perform the following actions:

  • Create records of any object type.
  • Update any related record; this is not limited to the record itself or its parent.
  • Use quick actions to create or update records or log calls.
  • Invoke a process from another process.
  • Launch a flow.
  • Send an email.
  • Post to Chatter.
  • Submit a record for approval.
  • Call an Apex class.

The Process Builder also comes with an easy-to-read and easy-to-edit drag and drop graphical interface; this is why most people call it WFR on steroids:

Lightning flow

When it comes to flows, you might have heard of several different definitions or types. To clear up any confusion, the official terms are as follows:

  • Lightning flow: This is the native platform feature that allows you to build, manage, and run processes
  • Cloud Flow Designer: This is the graphical interface that is used to design and build your flows; this is done through clicks and dragging and dropping
  • Flow: This is an actual chain of events, input captures, queries, and actions that will be executed to automate your specific business process when an event takes place in your Salesforce org or on an external system

In short, the Cloud Flow Designer is the tool that helps you create flows:

The flowscreen example

Every flow consists of three blocks, as follows:

  • Elements (1): These are dragged onto the canvas; an element can represent a screen input, a query or some kind of action (such as create record), a post to Chatter, and more.
  • Connectors (2): These are used to define the order in which elements are executed. They form the path that elements must follow, and they tell the flow what elements must be executed next.
  • Resources (3): These are pieces of storage in the memory of the flow that contain a specific value, such as values from fields or formulas. You can refer to and use these resources throughout your flow; for example, to look for an account's ID, store that ID in a variable resource with a name of your choice, and then later use that ID to update the account or to relate records to that account ID.

Additionally, Lightning flow is the only automation tool that can accept user input without the need to create a Visualforce page or Lightning component for it.

So, Lightning flow is an ideal tool for building—such as for call scripts, in which you guide users through a set of questions to ask a customer and, then, depending on the response, it performs a set of actions at the end of the flow. Additionally, Lightning flow is the only automation tool that is able to delete records.

Salesforce has a very nice comparison chart of the different automation tools, which you should know by heart for the exam. You can keep checking for any updates to this chart at

Consider the following screenshot: