How to PASS Salesforce Certified Platform Developer I Exam (Part 1 of 2)

How would you like to get certified in one of the fastest growing CRM platforms in the world? Perhaps you have already thought about taking a certification, but may be wondering where to start. Well, you've landed at just the right spot!

In this 2-part blog series, I will guide you through a Study Plan that will allow you to work at your own pace, set your own target and join thousands of other developers like you that have become part of the Certified Salesforce Community.

Salesforce offers a number of certifications that can be found here.

If you are happy configuring the platform with a point-n-click approach, the Salesforce Certified Administrator is a good start. However, if you're like me, and will only be satisfied learning the underpinnings of the platform, the best place to start in my opinion is the Salesforce Certified Platform Developer I.

Prerequisites

Before we get started, I would highly recommend creating a free Salesforce Developer Account by going here. The account will entitle you to:

• A free Developer instance of Salesforce.
• Access to hundreds of free online courses at Salesforce Trailhead. (This will likely become your favorite go-to spot, so feel free to check it out now.)

In addition to the above, the only other prerequisites are:

• Experience programming in an Object-Oriented programming language like Java or C#.
• Willingness to learn a new Object-Oriented programming language a.k.a Apex.
• Willingness to read a lot of reference material.

But fear not! Like any certification, there is a method to the madness and I will guide you through a strategic approach of making it through successfully.

What do you need to know?

You can find the latest Exam Guide here. The biggest take-away from this guide is that it outlines the percentage of questions that will be asked for each section. If there are 60 questions, below is a breakdown of the sections with the approximate number of questions that will be asked.

Section	Weight	Questions
Logic and Process Automation	46%	27 or 28
Testing	12%	7 or 8
Data Modeling and Management	12%	7 or 8
User Interface	10%	6
Debug and Deployment Tools	10%	6
Salesforce Fundamentals	10%	6

If the Passing Score is 65%, that means you need to correctly answer at least 39 questions. This might seem like an easy target to achieve, however, I should warn you that most, if not all, questions have more than one correct answer. That means if you get 2 out of 3 choices correct, but not the 3rd one, then that question will be marked as incorrect.

Let's not worry about that right now. By the end of this blog series, I am hoping you will comfortably answer most of the mock exam questions correctly.

What's our strategy?

The goal is to obtain 90% so you are well above the passing score. We will work on the sections from most-weighted to least-weighted, giving us the most coverage early on in your learning path.

The structure of this study guide is inspired by the 8-Question Strategy, which simply states that for passing this exam, or any Salesforce exam, you need to master the answers to 8 questions for each topic. Hence, we will attempt to answer the following questions (wherever it makes sense) for each topic.

1. When should this feature be used?
2. How does this feature work?
3. What is the customization potential of this feature?
4. When should you NOT use this feature?
5. What are similar features, and when should they be used instead?
6. How do you report / monitor the feature?
7. How does this feature work within Salesforce's security model?
8. Are there any limits around this feature?

Let's start with the end game. Let's think about and set a target date for when you will take the exam. Based on my experience, it would take anywhere from 80 - 120 hours of studying, mostly dependent on how much you know already and how quickly you can learn new concepts. Depending on how many hours you can dedicate on a daily basis, do the math, give yourself an extra few days, and go ahead and register for the exam.

I also recommend taking Mock exams after completing every section. The link to a website that provides Mock Exams by section, can be found in the Reference Material section at the end.

The remaining portion of this blog will cover the Logic and Process Automation section and we'll cover the remaining sections in Part 2.

Logic and Process Automation

Before diving into the topics for this section, let's review some basic concepts:

• Sales Cloud Data Model:

• Salesforce Security Model:

Now that we got our basics covered, let's get to the topics.

Describe how to programmatically access and utilize the object schema.

Apex provides two different ways of obtaining object and field descriptions. A Token is a serializable reference to the object or field type. A DescribeSObjectResult is a reference to an object or field description that is evaluated at run-time. Please review the Dynamic Apex section of the Apex Developer Guide.

When should this feature be used?

Since a Token is evaluated at compile-time, it is recommended to use that in favor of DescribeSObjectResult

How does this feature work within Salesforce's security model?

This will be a recurring theme for many other topics. Apex code runs in two modes; Either system mode, or anonymous block. Any apex code that is run in system mode, which is all Apex classes and triggers, the system does NOT enforce any restrictions on the sObjects that can be fetched dynamically. Therefore, it is recommended that any code that runs in system mode excplicitly checks for user permissions using DescribeSObjectResult. For example, the following code will be evalulated against the logged-in user's permissions:

Schema.sObjectType.Contact.fields.Email.isUpdateable()
Schema.sObjectType.Contact.isDeletable()

On the other hand, any code run in the anonymous block will enforce all user permissions.

Are there any limits around this feature?

When you describe sObjects and their fields from within an Apex class, custom fields of new field types are returned regardless of the API version that the class is saved in. If a field type, such as the geolocation field type, is available only in a recent API version, components of a geolocation field are returned even if the class is saved in an earlier API version

Describe the capabilities and use cases for formula fields.

There will most certainly be multiple questions on this topic embedded within different scenarios. But the main concepts to remember here are:

• Cross-object formula always works from child to parent means you can create formula on child to reference parent only.
• Cross-object formulas can reference merge fields from a master ("parent") object if an object is on the detail side of a master-detail relationship.
• Cross-object formulas also work with lookup relationships.

If parent has to refer to its child then it has to be a roll-up summary field (in a master-detail relation), or trigger for complex logic.

What is the customization potential of this feature?

A formula field can be of the following types:

• Checkbox
• Currency
• Date
• Date/TIme
• Number
• Percent
• Text

How does this feature work within Salesforce's security model?

Formula fields that a user can see may reference fields that are otherwise hidden or read only for that user. Therefore, if a formula field contains sensitive information, configure field-level security directly on the formula field.

Are there any limits around this feature?

Formula Fields can reference field values from related Parent objects that are up to 10 relationships away.

Describe the capabilities and use cases for roll-up summary fields

A roll-up summary field calculates values from related records, such as those in a related list. You can create a roll-up summary field to display a value in a master record based on the values of fields in a detail record. The detail record must be related to the master through a master-detail relationship.

What is the customization potential of this feature?

The following types of calculations are supported by a roll-up summary field:

• Count the number of detail records
• Sum of detail records
• Min value across all detail records
• Max value across all detail records

How does this feature work within Salesforce's security model?

Similar to formula fields, data that would otherwise be unavailable to users due to field-level security, can potentially be exposed to a user via roll-up summary field. Therefore, always configure field-level security for the roll-up field, if the detail record has field-level security.

Are there any limits around this feature?

When you delete a child record on a roll-up Summary field, Salesforce doesn't recalculate the value of the field. Select the Force a mass recalculation on this field option on the edit page of the roll-up summary field to manually recalculate the value.

Also, calculating roll-up summary field values can take up to 30 minutes, depending on the number of records affected and other factors.

Describe the capabilities of the declarative process automation features

Salesforce provides multiple tools to automate your org's repetitive business processes. They are:

• Lightning Process Builder
• Visual Workflow
• Workflow Rules
• Approvals.

Process Builder includes almost all the functionality that's available in workflow rules, and more. The only thing you can do with workflow that you cannot do with processes is send outbound messages without code.

If the process is too complicated for the Process Builder or requires more advanced functionality (nested if/else conditions, OR sort through, iterate over, and operate on several records), create a flow by using the Cloud Flow Designer.

If you need to build a wizard to collect information, Visual Workflow is the tool for you.

There is a very handy Cheatsheet created by Salesforce for Process Automation. There will certainly be a number of questions on this, so study it almost to the point of memorization.

How does this feature work?

Workflow rules and Processes associated with a record, are executed AFTER Auto-Response rules, anytime a record is changed.

Immediate actions are processed in the same transaction as the operation that triggered the process. Scheduled actions are processed in a separate transaction.

Other processes can be invoked from either Immediate actions or Scheduled actions.

Best practice for creating Invocable Processes are:

• When a group of actions needs to be used by more than one processes
• When there are nested if/else conditions

Are there any limits around this feature?

After you deactivate a process, the scheduled actions continue as usual.

If a scheduled actions fails (for any reason), Salesforce sends an email to the Admin AND retries the action. If multiple retries fail, the action is taken out of the queue.

Scheduled actions are grouped in a batch and executed within 1 hour after the first group enters a batch. If a group of actions hits a governor limit, none of the actions in that group are executed. Salesforce does continue to process the remaining groups in that batch.

Describe when to use declarative automation features vs. Apex classes and triggers

The Salesforce Platform is ever evolving. They offer 3 releases each year, packed with new and improved features. The platform offers a comprehensive set of REST and SOAP APIs and there is a huge effort by Salesforce of exposing more and more capabilities declaratively. All declarative capablities have already been tested and verified by the platform engineers. Hence, it is always a good idea to try to find solutions that offer declarative approach. Apex classes and triggers should only be used when the solution is either too complex, or just not possible using declarative features.

Following are scenarios that are better suited for Apex classes and triggers:

• Create Web services.
• Create email services.
• Perform complex validation over multiple objects.
• Create complex business processes that are not supported by Process Builder.
• Create custom transactional logic (logic that occurs over the entire transaction, not just with a single record or object).
• Attach custom logic (aka Trigger) to another operation, such as saving a record, so that it occurs whenever the operation is executed, regardless of whether it originates in the user interface, a Visualforce page, or from SOAP API.

Describe the primitive and complex Apex data types and when to use them

The following primitive data types are supported:

• Blob
• Boolean
• Date
• Datetime
• Decimal
• Double
• ID
• Integer
• Long
• Object
• String
• Time

You can find descriptions and rules for each here

And like many other languages, following complex types are supported:

• List
• Set
• Map
• Enum

Describe how to declare variables and constants in Apex and how to assign values using expressions

This one is pretty straightforward so we won't spend much time on it. Here's where you'll find the details:

• Variables
• Constants

Describe how to use and apply Apex control flow statements

The Control Flow section of the Apex Developer Guide is all you need to review, for this topic.

Describe how to write and when to use Apex classes and interfaces

Here's the definition of an Apex class:

private | public | global
[virtual | abstract | with sharing | without sharing]
class ClassName [implements InterfaceNameList] [extends ClassName]

The default access modified for inner classes is private

Describe how to use basic SOSL, SOQL, and DML statements when working with objects in Apex

If you recall, I had mentioned signing up for Salesforce Trailhead. Well, if you haven't done so, now would be a good time as it has a LOT of content around this topic. Here are the links to take you directly to the respective topics:

• SOQL
• SOSL
• DML

There are 2 ways of performing bulk DML operations:

• Use DML statements surrounded with try-catch blocks to either commit all or none.
• Use the <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_database.htm" target="_blank" rel="noreferrer noopener"><code>Database</code></a> class to perform partial commits.

Lastly, there are several column suffixes that you will see in various code snippets. The most common ones are:

• __c: custom object/field name
• __r: relationship column
• __s: for latitude and longitude columns

Are there any limits around this feature?

Certain objects in Salesforce can only be changed declaratively, and there are no DML methods available for them. The complete list can be found here, however, some of the more common ones are below:

• ApexComponent
• ApexPage
• CurrencyType
• Profile
• RecordType

Describe the basic patterns used in triggers and classes to process data efficiently

• Assume Trigger.new and Trigger.old will return multiple objects
• Minimize the number of data manipulation language (DML) operations by adding records to collections and performing DML operations against these collections.
• Minimize the number of SOQL statements by preprocessing records and generating sets, which can be placed in single SOQL statement used with the IN clause.
• Have one Trigger class Per Object
• Encapsulate trigger logic into helper classes with static methods
• Use a Trigger framework that should help with the following:
  • Routing Abstractions (beforeUpdate, afterInsert, etc) Recursion Detection and Prevention
  • Centralize Enable/Disable of Triggers
  • Easier collaboration on large development teams

Describe when to use and how to write triggers

Trigger.New contains all the records that were inserted in insert or update triggers. Trigger.Old provides the old version of sObjects before they were updated in update triggers, or a list of deleted sObjects in delete triggers.

For a complete list of variables available in a trigger, refer to Trigger Context Variables

How does this feature work?

Triggers execute on batches of upto 200 records at a time

What is the customization potential of this feature

Use sObject.addError() method to generate a run-time exception in a trigger. For additional capabilities, refer to Context Variable Considerations

Are there any limits around this feature?

At the time of this writing, the platform allows:

• 100 SOQL queries for synchronous Apex
• 200 for asynchronous Apex
• 150 DML calls in one transaction

Describe the implications of governor limits on Apex transactions

Unfortunately, sometimes certifications require you to just memorize some stuff. Here are the Apex Governor Limits imposed by the platform.

Describe the relationship between Apex transactions, the save execution order, and the potential for recursion and/or cascading

With Great Power, comes Great Responsibility. The platform offers a multitude of features for adding custom business logic. The business rules encoded in these features like validation rules, Processes, Workflows, Roll-up Summaries, Cross-object formula, etc, etc are executed in a certain order. There will most definitely be a question or two on the Order of Execution and it is best to learn it by heart. If there is one take-away from this section, it would be that Triggers can potentially execute twice in certain situations.

Describe how to implement exception handling in Apex

The exception handling in Apex is very similar to other languages like Java and C#. A difference, though, is method does not have to declare the exceptions that it may throw. For more info, checkout Exception Statement

Describe how to write Visualforce controllers

As Salesforce is slowly retiring Visualforce, in lieu of Lightning, there won't be a lot of emphasis on Visualforce. Generally, it would be a good idea to skim through the following sections, specially understanding when to use a custom controller and/or a controller extension:

• Building a Custom Controller
• Building a Controller Extension
• Building a Custom List Controller

Describe when and how to use standard Visualforce controllers vs. Apex custom controllers and controller extensions

If you want to override existing functionality, customize the navigation through an application, use callouts or Web services, or if you need finer control for how information is accessed for your page, you can write a custom controller or a controller extension using Apex. For example, use custom controllers when you want your Visualforce page to run entirely in system mode, which does not enforce the permissions and field-level security of the current user. Use controller extensions when:

• You want to leverage the built-in functionality of a standard controller but override one or more actions, such as edit, view, save, or delete.
• You want to add new actions.
• You want to build a Visualforce page that respects user permissions. Although a controller extension class executes in system mode, if a controller extension extends a standard controller, the logic from the standard controller does not execute in system mode. Instead, it executes in user mode, in which permissions, field-level security, and sharing rules of the current user apply.
• If you want to sort by non-default column(s) OR if you want more than 10,000 records to be returned, use a custom controller.

Describe the programmatic techniques to prevent security vulnerabilities in Apex and Visualforce

Here's a collection of measures that should be taken to be compliant with Secuirty standards:

• Use with sharing to enforce OWD, Role Hierarchy and Sharing Rules
• Use Schema.DescribeSObjectResult to enforce object and field level user permissions
• Use Apex Class Access to limit the users that have access to a particular Apex class
• For and custom Javascript use
• Ensure text displayed on pages is html encoded
• If you have to use dynamic SOQL, use escapeSingleQuotes. Otherwise, preferably use static SOQL with binding variables

Describe how Apex impacts the ability to make declarative changes

Use Apex as a last resort and try to use declarative features as much as possible. The more code that is written, the more time will be spent in writing, maintaining and updating it to future platform versions. The same time (and energy) should be spent working with declarative features, whenever possible.

Let's take a moment to appreciate what we've covered so far. If you go back to the exam outline, you'll notice we've covered a whopping 46% of the exam, which was all centered around Logic and Process Automation. Hope you've enjoyed the ride so far! In the next episode, we'll cover the remaining portions of the exam, namely, Testing, Data Modeling and Management, User Interface, Debug and Deployment Tools and Salesforce Fundamentals.

Reference Material

• Salesforce User Guide
• Apex Developer Guide
• Visualforce Developer Guide
• SOQL and SOSL Reference Guide
• Mock Exams

In addition, the following blog posts were used as a reference for some of the content in this blog:

• Study Guide by Snehal Surti
• Study Guide by Ruben Ortiz

If you are ready to dive into the remaining topics, you can click here to go to Part 2 of this blog series.