Free Salesforce Platform Developer I Practice Exam (with Answers)

While all the options presented can fulfill this task, a Before-save flow is the best option in this scenario.While Workflow rules and Process Builders have been a tool of choice for this type of automation for many years, these two tools have been deprecated and so any new functionality should not be built on them. Instead, a Flow should be used as this is the replacement technology. An Apex Trigger is not a valid choice here since it would increase the maintenance overhead of a solution which can easily be achieved in the platform’s low-code tools.

References:

• Salesforce to Retire Workflow Rules and Process Builder
• Go with the Flow: What’s Happening with Workflow Rules and Process Builder?

To utilise scratch orgs, the Dev Hub must be enabled in an org to allow scratch orgs to be created. Each developer wishing to create scratch orgs from that Dev Hub must have a user with the correct permissions to manage scratch orgs and access the scratch org objects in that org. Using the Salesforce CLI this user can login into the Dev Hub and be used to request the creation of scratch orgs.

References:

• How to Enable Dev Hub
• Add Salesforce DX Users
• Create Scratch Orgs

If we wish for a method or a variable to be able accept any type of Salesforce Object, we use the SObject type class. All Salesforce Objects extend the generic SObject class and so, when a method must accept different types of objects, we must define our datatype to be the generic SObject type instead.

While it is true that we could also use 2 – Object data type – since everything in Apex extends this type, it would allow our method to take in unnecessary data types, such as Boolean or String.

When we write our unit tests, one of the most important and time-consuming steps is setting up test data. Two strategies to help reduce the effort required is to utilise a test data factory and to utilise a @TestSetup annotated method within our test class.

A test data factory is a class that we set up, which contains several different methods designed specifically to create generic records and their dependencies exclusively for use within test classes. This greatly increases the ease of setting up records for our tests.

The @TestSetup annotated method within a test class is designed entirely for the setting up of data within the test. This method is called before any tests are run and allows the test records to be created before the tests themselves are run. It also creates a snapshot of the created data which is rolled back to, so after each test method has been run each test gets a fresh set of data, much quicker than having to set it up itself.

References:

• TestSetup Annotation
• Create Test Data for Apex Tests

When we wish to flag an Apex method as cacheable, so the result should be cached client side, we must modify our Apex method to indicate so. We do this by adding the “cacheable = true” parameter to the @AuraEnabled annotation.

The setStorable method must be used if we wish for an Apex action to be cached within an Aura component, however there is no such requirement when we are working with LWCs.

References:

• AuraEnabled Annotation
• setStorable() in Aura Components

The SOQL engine within Apex is incredibly flexible in how we can call it, and how it returns data for us to consume with the code. The most common return type is a List<SObjects>, this will be when a simple query is run. The SObject return type can be used when a query is known to return a single record only, for example when using a LIMIT 1 or querying for a specific ID. The integer return type is used when we use the COUNT query function.

References:

• SOQL and SOSL Queries

The multi-tenant architecture within Salesforce presents developers with several considerations that must be taken when they are writing code for the platform.

The design of the multi-tenant system prevents any data from being accessed outside it’s intended org, which means additional security considerations (outside the usual ones) aren’t required, simply because of the multi-tenant nature.

The platform resources are, however, shared and all orgs within instances are using the same CPUs and memory for all of their Apex operations and it is here where the considerations must be made. These considerations are to ensure that Apex code is performant as any code deemed to be using excessive resources (as defined by the governor limits) will be terminated to prevent it from monopolising resources and causing detrimental effects on other tenants.

References:

• Salesforce’s Multi Tenant Architecture

The variables which are present within a Trigger are dependent on the current trigger context. In this case we are operating in a Before Insert context, this means the record hasn’t been inserted into the database yet and so there can be no old value for the record, and so the Trigger will throw a null pointer exception on line 2.

References:

• Trigger Context Variables

The Wire service is designed to provision a component with an immutable stream of data to a component that is ever updating. Because of this, the values returned by the Apex methods must be cached and so we must always annotate a method intended to be used by the Wire service with @AuraEnabled (cacheable = true).

References:

• Understand the Wire Service
• Wire Apex Methods to Lightning Web Components

Visualforce pages are the only on-platform technology that can be used to render PDFs, and since the PDF to be generated here is simple, utilising this functionality is the best approach.

For more complex PDFs, utilising an AppExchange app would be preferred since it wouldn’t require developers to build something from scratch, and instead would only require installing an App.

References:

• Render a Visualforce Page as a PDF File

Outside of reviewing code from inbound changesets, there is no way to view Lightning Web Components on the platform. Instead, we must utilise an external tool to view the source code for these. The Salesforce extension pack for VSCode is one such tool for this. While the extension pack utilises the Salesforce CLI for a lot of its operations, the CLI on it’s own isn’t capable of reviewing the source code for LWCs and is instead used to communicate with the Salesforce servers (e.g. deploying and retrieving the LWCs), but not for writing the code directly.

References:

• Set Up Your Development Environment – Salesforce Lightning Component Library
• Salesforce Extensions for Visual Studio Code

The Security class methods are designed explicitly for easily enforcing the FLS of the current user by stripping anything which is not accessible in the defined context.

While checking each field’s accessibility using the DescribeSObjectResult for the SObject is a valid approach, it is far more verbose and requires a lot more code to achieve the same results as utilising the Security.stripInaccessible() methods.

References:

• Enforce Security With the stripInaccessible Method

To easily create record forms, a lightning-record-form component is the best choice. This component can be used to rapidly create forms based on a list of fields or layouts for an object choice, which can allow admins to maintain the forms without requiring developer intervention.

References:

• Create a Record – Salesforce Lightning Component Library

The Lightning Web Component framework has been built on top of the Web Components web standard, with a focus on writing standard JavaScript and HTML. This lets the framework be lightweight and have lightning-fast performance.

The use of Web Components allows code to be designed and built quicker, by utilising the compositional nature of Web Components, alongside an ever growing library of base components.

References:

• Create a Record – Salesforce Lightning Component Library

The naming scheme for events within Lightning Web Components follows the DOM event standard. This means that all event names must not use uppercase letters, have no spaces, and use underscores to separate words.

References:

• Create and Dispatch Events – Salesforce Lightning Component Library

For a complex task such as this, the first step should be investigating whether there has been an app released on the AppExchange which fits your use case. If there are no suitable AppExchange apps, only then should custom development be considered.

Formula fields are special fields within Salesforce, regardless of how they are accessed, their value is only calculated when they are accessed. If they are accessed within Apex or a Flow, this may be the first time they are accessed, such as when the field was queried. However, in Apex these values can be requested to be recalculated.

Fields referenced within a formula can reference other objects by using relationship spanning fields, i.e. referencing the Account Name from a formula on Contact would be done using “Account.Name”.

Formula fields have a compile time maximum character limit of 3900 characters, this limit can be extended by referencing other formulas, however there is a compile time maximum limit on the size of the formula (5000 bytes), which considers other formula field’s size.

References:

• Formula Field Limits and Restrictions
• Formula Operators and Functions

External Ids allow flagging a field as an Id which is used within an external system. This allows the field to be utilised in Upsert calls, where instead of specifying the Salesforce Id for a relationship field, the external Id can be used instead. The external Id is then used to find the record within Salesforce and the relationship field value gets replaced with its Salesforce Id instead. This type of operation is supported by the Data Loader tool.

Utilising manual methods of doing this match introduces the risk of human error when re-establishing the relationships.

References:

• Can I import using external IDs?
• Differences between the ‘External ID’ field and the ‘Unique ID’ field setting

A custom exception is a class (either inner or top level) which extends the built in Exception class. The only restriction is that the class name ends with “Exception” however, there are no other limitations around the custom class, that is they can have their own methods, constructors, or member variables as required.

References:

• Create Custom Exceptions | Apex Developer Guide

When we are operating on the Trigger.New context variable in a before operation we have access to, and can modify the Trigger.New object field values. These changes are done before the data is committed to the database, and any modifications to Trigger.New will go on to be committed to the database when the transaction ends.

Since the trigger context is a before insert, no records have been assigned an Id yet, so DML operations on these records cannot be performed, and instead would need to be performed in an after context.

References:

• Context Variable Considerations

Flows can be invoked from numerous different sources; these can be split into two categories. Screen based flows which combine automated processes with screens presented to a user. The other type are headless flows, these run without any user interface, just like Apex triggers.

Headless flows have many invocation mechanisms, which can be further categorised into record triggered, scheduled, and externally triggered. Like the name suggests, record triggered flows are triggered from record actions, such as save or update, and can operate in both a before and after save context. Scheduled flows are time-based flows, invoked at a specific time or interval. Lastly invokable flows are invoked via something external to the flow, this could be another flow, a process builder, Apex or via the API.

While test coverage is generated for flows, it is not a requirement to get 75% test coverage for a flow to be deployed to production, unlike Apex.

References:

• Triggers and Order of Execution
• FlowTestCoverage | Tooling API | Salesforce Developers
• Triggers for Autolaunched Flows
• Distribute a Flow

SOSL queries return a List<List<SObject>>, with each list being the results for a specific SObject type, the order of which is the same as defined within the query. I.e. if Account was the third SObject in the RETURNING clause, the list at the second index would be a list of the Account results. This is because SOSL queries are performed against multiple objects at once.

References:

• SOQL and SOSL Queries | Apex Developer Guide

The instance variable is initially initialised as 1 during the constructor of the batch class. This is then incremented by 1 for each execute method run. Since this batch class also implements Database.Stateful, the instance variables of this class are preserved after each execute method call, hence why the output value is 4.

References:

• Using Batch Apex

Lightning Components can be exposed in a wide number of places across the Salesforce ecosystem, with the main target’s being the Lightning Experience, Experiences and in the Salesforce Mobile App.

Lightning Components cannot natively be used within Salesforce Classic, instead Visualforce pages must be used which can load Lightning Components via Lightning Out.

There are a large number of other places where Lightning Components can be used.

References:

• Supported Salesforce Targets and Tools – Salesforce Lightning Component Library

Lightning Components can make use of the EMP API to subscribe to any type of platform event published, this can include generic events and Change Data Capture events.

References:

• Subscribe to Platform Event Notifications in a Lightning Component
• lightning-emp-api – documentation – Salesforce Lightning Component Library
• lightning:empApi – documentation – Salesforce Lightning Component Library

When running a query which returns no rows, a “List has no rows for assignment to SObject” error will be thrown. An index out of bounds error would not be thrown in this scenario since we are not directly trying to access an element from an array.

References:

• “List has no rows for assignment to SObject” Error

To exit out of a for loop early we can use the “break” statement which stops any code after it, and any additional items which would have been looped over from being run.

The “continue” statement is used when we wish to exit the current loop iteration early and progress onto the next one.

References:

• Apex Loops

To access field metadata within Apex we use the FieldDescribeResult for the field we are interested in, this can be accessed declaratively as in the answer to this question, or programmatically as shown below.

We access the picklist values of a field by calling the getPicklistValues() method on it’s describe result, this returns us a List of PicklistEntry which we can use as desired.

References:

• Schema.PicklistEntry Class

There are three sharing keywords available in Apex, With, Without and Inherited. With and Without sharing explicitly run a class with or without sharing enforced. The third, Inherited, is a little different; Inherited sharing takes on the sharing declaration of the class which has executed the code, so if a class with sharing enforced calls a method in a class with inherited sharing, the inherited sharing class code would run with sharing enforced. This is really useful for when the sharing model to be used isn’t known at design time, or the code is built to be called from varying places within the system.

References:

• Apex Sharing Keywords

Before a field can be deleted all references to that field must be removed. These references could be found within declarative tools, such as reports and flows, or within code. Attempting to delete the field which is referenced elsewhere will throw an error.

References:

• Deleting Fields

When we wish to configure the DML operation, or handle failed records, we must use the Database class methods. When we specify false for the allOrNone parameter, instead of an exception being thrown when any record encounters an error during save, a List<Database.SaveResult> is returned instead of an exception being thrown.

We can use the returned result to customise any error handling required for specific records.

References:

• DML Statements vs. Database Class Methods

Whenever an unhandled exception is thrown in a transaction (such as an uncaught save error from a validation rule), the entirety of the transaction is rolled back – i.e. the state of the database reverts to how it was before the save request was made. This happens regardless of where the error occurs.

References:

• Trigger Exceptions

When building components that work on individual records, the Lightning Data Service provides a performant and cached mechanism for loading and updating record data that gets propagated throughout all components utilising the service.

This offers advantages over performing Apex calls to achieve simple record data since it increases performance and allows changes in other areas of the UI (for example for the standard record details component) to propagate to other components.

References:

• Lightning Data Service

When we are performing code which we consider dangerous due to its chance of throwing an Exception, we can wrap this code within a try-catch block.

Try-catch blocks are made up of two parts. The first part is the try block, this is where the dangerous code is executed. The second part is the catch block, this block (or blocks if handling specific exception types) allows us to write code which gracefully reacts to errors and allows the code to continue to execute. Optionally a third block can be included, the finally block, this executes a block of code after either the try successfully runs, or a catch block finishes executing.

References:

• Exception Handling Examples

Any area where user input is used to query data within the database should be considered an avenue for attack and should be protected against.

Sanitising the user input protects against SOQL injection by ensuring values are treated as values and not accidently interpreted as extensions to a query. This is easily achieved with bind variables.

The “WITH SECURITY_ENFORCED” clause of a query prompts the SOQL engine to enforce permissions on the query, so if a query attempts to access a field or object the user doesn’t have access to, an exception is thrown.

A piece of Apex should never trust search parameters from a Lightning Component as these could easily be manipulated. Instead, in scenarios where this is required, alternative approaches should be used such as hardcoding the filter variables in an Apex datatype or as parameters to the method, in order to ensure that any requested fields/filters have been explicitly pre authorised.

References:

• Lightning Security Considerations

Lead conversion causes Apex triggers to fire, the scope of which depends on the records the Lead is being converted to, but at a bare minimum the triggers on the Lead object are fired. If a Lead is creating or updating any secondary objects, those objects also have their triggers fired.

References:

• Considerations for Converting Leads

Roll-up summary fields are a feature of Master-Detail relationship that allow the Master record to calculate details about all of it’s detail records, e.g. a count of the number of Detail records belonging to a Master record.

References:

• Roll-Up Summary Fields

Test classes come in three distinct parts:

1. Setup – preparing data and the runtime environment for your testing scenario
2. Execution – executing the code you wish to test
3. Validation – verifying the results of the executed test against the expected results

The process of setting up and preparing a test can result in the consumption of many governor limits before the actual code we wish to validate has been run, for example having to insert Accounts if you wish to validate a rollup from Opportunity.

This is not an ideal scenario as it causes our test execution to potentially not run in a realistic environment. We can use the Test.startTest() method just before executing the code we wish to test to assign that block of code a new set of governor limits. We can then call Test.startTest() once we’ve finished our execution and are ready to validate our results.

If we are testing asynchronous apex (e.g. a batch class), since the code gets flagged to run at an unknown future date, we would not be able to write tests for any asynchronous methods. Instead by wrapping the code execution in Test.startTest() and Test.stopTest(), when the stopTest method is called, the async code is executed and so we can test the results of the execution within our test class.

Switch statements allow a developer to test whether an expression matches one of several different values in a branch, and perform some code based on the matching branch.

In the question, the switch operation compares an Enum value against several options. Since the value operation is AFTER_INSERT, the switch statement evaluates each branch until it matches the AFTER_INSERT value, which executes the code block, which sets foo to equal 30.

References:

• Apex Switch Statement

The standard controller for Visualforce provides lots of data access opportunities for the record it is operating on. Notably, it allows access to parent objects, being able to traverse up 5 levels of parent child relationships. For example, you could access details about an Account records owner from an Opportunity. The standard controller also offers 1 level of parent-child traversal, i.e. you could access the Contacts belonging to an Account.

References:

• Accessing Data with a Standard Controller

The LWC framework follows the HTML specification for how it expects HTML to be written within component templates. This means that for any components that aren’t base HTML tags, it is required that no component tags are self-closing (i.e., there is always an explicit closing tag).

In LWC, when we wish to display picklists, we should utilise the base component called combobox. In Aura, we can either use the combobox or the select components, however in LWC we only have the combobox as there is no lightning-select component.

References:

• LWC HTML Template file
• lightning-combobox base LWC documentation

Anonymous Apex code can be executed both on platform and off platform. On platform this is done directly in the Developer Console, utilising the Developer Console’s inbuilt functionality.

When we wish to run code off platform, there are several ways this can be achieved. One of the easiest is to utilise the Salesforce CLI commands, as these can run code directly from either a terminal, or from code stored within a file. Lastly we can utilise either the SOAP or the REST APIs to send code to Salesforce to be executed.

References:

• Executing Anonymous Apex Code in the Developer Console
• Salesforce CLI: Execute Apex
• REST Resource Examples: Running Anonymous Apex

Apex classes and some other metadata cannot be directly deleted from production. While these pieces of metadata can be deleted within a Sandbox, changesets cannot upload these destructive changes. Instead the Metadata API must be used. This could be with a tool such as ANT to produce a destructive changeset which is deployed into the org.

References:

• Deleting metadata from Production instances

Inner classes can have their own sharing modes declared, which don’t have to match that of the outer classes. This can be useful for nesting specific methods which require without sharing inside a class which has with sharing declared.

References:

• Apex Sharing Keywords

Test classes within Salesforce play a very important role: they are used to determine whether a piece of code is behaving exactly as it was intended to.

Properly written tests can act as early warning signs for when things go wrong, and can help easily identify specific pieces of code that are no longer behaving as expected (for example, due to conflicting with a recently introduced Process Builder or Flow).

References:

• Apex Test Classes

The StandardSetController is designed to work with sets of records, and so provides built in methods to enable a large set of records to be displayed on a Visualforce page, with methods to assist in pagination of the record list.

References:

• Pagination with a List Controller
• Visualforce StandardSetController methods

Each custom metadata type comes with its own SObject type in Apex. This type contains additional methods which can be used to declaratively obtain records from a custom metadata type by developer name or record Id. These methods are similar to those found on custom settings.

References:

• Custom Metadata Type Methods

The maximum number of records processed by a trigger at a time is 200. If the number of records being inserted is greater than this (e.g. from the Bulk API or a bulk DML operation), the trigger is invoked in batches of 200 records at a time.

References:

• Apex Triggers
• Bulkify Apex Triggers

Apex jobs can be scheduled in the UI via the Apex Scheduler or through writing a line of code to enqueue the job via code (e.g., submitting via the Developer Console).

The System.enqueJob() method is not used for scheduled jobs and is instead used to queue a queueable piece of apex, the main difference being queueable apex executes at the soonest possible time, whereas a scheduled job executes at the designated time.

References:

• Apex Scheduler
• Apex System Class

When doing a deployment into production, there must be an average of 75% code coverage for all Apex code within the org. Alongside this, Apex triggers being deployed must have at least 1 line being covered (i.e. they must have been called by at least one test class).

When running deployments, there is the option to run a subset of tests which changes the code coverage behaviour. When running the default testing mode, all tests are executed and the total coverage in an org must meet 75%. However, when running a specified set of tests, every item in the deployment must average 75% instead.

References:

• Apex Test Requirements
• Code coverage steps before deployment
• Code coverage best practice

Standard validation rules are unable to operate on parent child relationships so Apex validation is required instead.

Apex validation allows complex validation logic to be performed on record save operations. This is done by processing the records for the required criteria, and then calling the addError() method on each individual method with the validation message a user should see as an argument for the method.

References:

Trigger Exceptions and Apex Validation

When multiple triggers are defined on an object, the order in which they are executed cannot be guaranteed or relied upon. Instead, it is a best practice to ensure only a single trigger is defined on an object which hands off to other classes to perform business logic.

References:

• Triggers and Order of Execution

Changesets are only available within a production org and its sandboxes. The purpose of them is to allow development and testing to be done in a metadata clone of a production org, and for those changes to be migrated into production when ready.

Since developer orgs are not tied to a production instance and are instead standalone, they do not feature changesets and so cannot be the target nor the source of a changeset deployment

References:

• Connecting Orgs for Deployments

Using the @TestVisible annotation allows a test method to access a private or protected method or class variable, instanced or static. This change in access is only applied for test classes and doesn’t affect the access of the class in any other way.

Utilising this annotation allows the original access modifier to be used without sacrificing the ability to precisely test a specific piece of code

References:

• @TestVisible Annotation

Lightning Web Components utilise the standard CustomEvent class within JavaScript, which is then dispatched through the EventTarget.dispatchEvent() method, which in the majority of cases, would be this.dispatchEvent() – since we would want parent components to handle this event.

We add information to the event with the detail property of CustomEvent, which the event handlers can access and process accordingly. The detail property can be any datatype.

We should follow the DOM event standard in the naming of our events, meaning no upper-case letters, no spaces, and underscores to separate words.

References:

• Create and Dispatch Events in LWC

Whenever we wish to use external resources within our application, we should upload them as Static Resources. Uploading the files as Static Resources improves our applications security, as it shifts the control of the resources to be ours, instead of a third-party site which could end up having malicious code embedded without our knowing.

Lightning Components require all third-party resources to be uploaded as Static Resources and loaded through the Platform Resource Loader, however Visualforce can reference external URLs.

References:

• Using External CSS in Aura
• Use Third-Party JavaScript Libraries in LWC
• Using Static Resources in Visualforce

SOQL for loops differ from a traditional for loop, or a List/Set for loop in that they can utilise more efficient chunking of SObjects behind the scenes, resulting in a reduced heap usage and a lower chance of hitting governor limits for large queries. This type of loop should be the tool of choice when iterating over query results as it can mitigate the chance of hitting errors as a dataset scales.

References:

• SOQL For Loops

Since a student can be enrolled on many courses, and a course can have many students enrolled, we require a junction object to keep track of each student enrollment.

The relationships used to create this junction object should be master-detail. This will prevent orphaned records from being created and ensure both lookups are always populated.

References:

• Object Relationships

All data stored within a number field (or number returning formula) is represented as a Double when accessed within Apex.

Reference:

• API Data Types and Salesforce Field Types

Visualforce standard controllers come in two varieties, StandardController and StandardSetController, operating on single and collections of records respectively and one is present for the majority of standard and all custom objects within an org.

Standard controllers contain several inbuilt methods and mechanisms to access data and save data, both of which when used explicitly enforce any permissions related to fields and object access.

Controller extensions can be built to define custom logic and actions to be performed within a controller, while retaining the functionality of the standard controller.

References:

• Standard Visualforce Controllers
• What are Custom Controllers and Controller Extensions?