Salesforce-Platform-Developer Practice Test Questions (2026)

Explanation:

The current trigger performs a SOQL query inside a for loop (line 06 → line 15). This is a common anti-pattern in Apex development because it can easily exceed the SOQL governor limit (100 queries per transaction) when processing many Account records in bulk (e.g., through a nightly integration).

To fix this:

Refactor getAssetsToUpdate() to accept a list of all updated Accounts and return all related Assets that need updating.
Move the query logic outside the loop so it runs once per trigger execution, not per Account.
This bulkification ensures the code scales and avoids SOQL limits.

Why Not the Other Options:<

B. Add a LIMIT clause to the SOQL query on line 16...
This would truncate the result set, possibly leaving some Assets unupdated, causing data inconsistencies. Not a valid fix for governor limits in a bulk operation.

C. Move all of the logic to a Queueable class...
Queueable is useful for async processing, but it still doesn’t solve the fact that the code runs SOQL inside a loop. You’d have to refactor the logic for bulk operations regardless.

D. Add List assets = ... to line 14 and iterate in the loop... This keeps the SOQL query inside the method, which is still being called from inside the trigger loop — same bulk processing issue. Just inlining the query won’t prevent hitting limits.

Explanation:

Change Sets are the recommended and declarative way to migrate metadata (including Apex classes, triggers, Lightning Components, and configurations) from a Sandbox to Production when both environments are connected via Salesforce Deployment Connections.

• They are user-friendly and do not require coding expertise.
• They support a wide range of metadata types, including custom objects, profiles, and Lightning components.
  

Explanation:

Rollup summary fields can cause the parent record to go through Save (A)

Master-detail relationships allow rollup summary fields on the parent object (Account) to aggregate data from child records (Branch).
When a child record (Branch) is inserted, updated, or deleted, the rollup summary field on the parent object (Account) triggers a save operation.
This means that even if a developer is modifying a Branch record, the Account trigger could also execute due to rollup summary field recalculations.

The trigger may fire multiple times during a transaction (B)

Apex triggers can fire more than once within a transaction, especially in scenarios like:
Recursive trigger execution due to updates made inside the trigger itself.
Before and After Triggers executing at different stages of the transaction.
Process Builder, Flows, or Rollup Summary Field recalculations causing additional trigger executions.
Developers need to use static variables or recursion guards to prevent unintended multiple executions.

Why Not C or D?

C. Duplicate rules are executed once all DML operations commit to the database →
Duplicate Rules execute before DML operations commit to the database.
They prevent duplicate records before inserting/updating, making this answer incorrect.

D. The validation rules will cause the trigger to fire again →
Validation rules do not directly trigger Apex triggers.
While they can prevent records from being saved, they do not cause a new execution of the trigger.

Explanation:

To ensure that a picklist field always has a value when a record is created or updated, the most efficient and enforceable approach is to:

✅ C. Mark the field as Required on the field definition

Setting a field as required at the field level (schema definition) ensures that no record can be saved (via API, Apex, UI, Flow, etc.) unless the field has a value.
This enforcement is universal — meaning it applies across all entry points.
This is the most efficient and robust method.

🔹 Reference: Salesforce Help: Make a Custom Field Required

❌ Why the others are incorrect or less ideal:

A. Set "Use the first value in the list as the default value" as True

This only sets a default value, but users or processes can still clear or override it.
It does not enforce that a value must be selected during record creation or update.

B. Set a validation rule to enforce a value is selected

This can work, but is less efficient than using the built-in "required" flag.
Also, it's additional configuration and logic that is unnecessary when a simpler declarative option (field-level required) exists.

D. Mark the field as Required on the object's page layout

This only makes the field required in the UI and only on that specific layout.
It does not enforce the requirement via API, Apex, Flow, or even other layouts.

Explanation:

In the code shown:

public static void insertAccounts(List theseAccounts){
for(Account thisAccount : theseAccounts){
if(thisAccount.website == null){
thisAccount.website = 'https://www.demo.com';
}
}
update theseAccounts;
}

The method always calls update theseAccounts.
If even one record in theseAccounts causes an error (for example, a validation rule, required field missing, or duplicate rule), the entire DML operation fails and throws a DmlException.
To handle such errors gracefully, a developer should wrap the DML statement in a try/catch block. This allows you to catch the exception, log it, and maybe handle records individually if needed.

Corrected Example with try/catch:
public static void insertAccounts(List theseAccounts){
for(Account thisAccount : theseAccounts){
if(thisAccount.website == null){
thisAccount.website = 'https://www.demo.com';
}
}
try {
update theseAccounts;
} catch (DmlException e) {
// Handle gracefully: log error or take corrective action
System.debug('Update failed: ' + e.getMessage());
}
}

Why not the other options?

A. Upsert → Wouldn’t solve the exception problem. Upsert only helps when you want to insert or update based on an external ID. Errors like validation failures would still throw exceptions.

B. Change Data Capture → This is for event-driven integration, not error handling.

D. Remove null items → That prevents null pointer issues but doesn’t stop DML exceptions (e.g., validation rules or required fields).

Reference:
Salesforce Apex Developer Guide – Exception Handling

Explanation:

The business requirement is to display whether a Contact’s Mailing State matches any value in the Preferred_Locations__c multi-select picklist on the Job__c object, within the related Job_Application__c record, and to keep this value in sync when the Contact’s Mailing State changes. Let’s analyze why a record-triggered flow is the recommended tool and why the other options are less suitable.

Why D. Record-triggered flow?

A record-triggered flow is a declarative automation tool in Salesforce that can be triggered when a record is created or updated. It’s ideal for this scenario because:

1. It can evaluate the Contact’s MailingState (from the Contact object) against the Preferred_Locations__c multi-select picklist on the related Job__c object (via the Job_Application__c master-detail relationship).

2. It can update a field on the Job_Application__c record (e.g., a checkbox or text field) to indicate whether the Contact’s MailingState matches any value in Preferred_Locations__c.

3. It can be configured to run when the Contact’s MailingState is updated, ensuring the Job_Application__c record stays in sync.

4. Flows are declarative, meaning no coding is required, which aligns with Salesforce’s preference for low-code solutions when possible, reducing maintenance overhead.

How it works:

1. Create a record-triggered flow on the Contact object that triggers on create or update when MailingState changes.

2. Use a Get Records element to retrieve related Job_Application__c records and their associated Job__c records.

3. Use a decision element to check if Contact.MailingState is contained in Job__c.Preferred_Locations__c (using the CONTAINS function for multi-select picklists).

4. Update a field on Job_Application__c (e.g., a checkbox Is_Location_Match__c) based on the result.

Why it’s recommended:

It’s a scalable, maintainable, and declarative solution that avoids custom code, aligning with Salesforce best practices for the Platform Developer I exam.

It can handle complex logic (e.g., multi-select picklist comparisons) without requiring Apex.

Why not the other options?

A. Roll-up summary field:

1. Roll-up summary fields are used to aggregate data (e.g., count, sum, min, max) from detail records to a master record in a master-detail relationship. They cannot perform complex logic like comparing a Contact’s MailingState to a multi-select picklist (Preferred_Locations__c) on the master Job__c object.

2. Roll-up summaries are limited to simple calculations and cannot dynamically check for matches or update fields based on external object data (e.g., Contact’s MailingState).

3. This option is incorrect because it doesn’t meet the requirement for dynamic comparison or synchronization.

B. Apex trigger:

An Apex trigger on the Contact object could achieve the requirement by:

1. Triggering on update of MailingState.
2. Querying related Job_Application__c and Job__c records.
3. Comparing MailingState with Preferred_Locations__c using Apex logic (e.g., splitting the multi-4. select picklist values).
4. Updating a field on Job_Application__c.

However, Apex is a coded solution, and Salesforce encourages declarative tools (like flows) over code when the functionality can be achieved declaratively, especially for the Platform Developer I exam, which emphasizes low-code solutions where possible.
While technically feasible, an Apex trigger is overkill and increases maintenance compared to a flow.

C. Formula field:

A formula field on Job_Application__c could theoretically compare Contact.MailingState (accessed via the master-detail relationship) to Job__c.Preferred_Locations__c using the INCLUDES function for multi-select picklists.

Example formula:

INCLUDES(Job__r.Preferred_Locations__c, Contact__r.MailingState)

This would return true if the MailingState matches any value in Preferred_Locations__c.

However, formula fields are recalculated on read (not stored in the database), which can lead to performance issues if used extensively in reports or list views. More importantly, formulas cannot trigger updates or ensure synchronization when MailingState changes—they are passive and only display data.

The requirement to “keep in sync” suggests an active update process, which a formula field cannot provide. Thus, it’s not the best fit.

Key Considerations:

Master-Detail Relationships:
Job__c is the master of Job_Application__c, and Contact is the master of Job_Application__c. This allows the flow to navigate relationships (e.g., Job_Application__c.Job__r.Preferred_Locations__c and Job_Application__c.Contact__r.MailingState).

Multi-Select Picklist:
The Preferred_Locations__c field requires a CONTAINS or INCLUDES check to compare against MailingState. Flows can handle this using formula expressions or decision elements.

Synchronization:
The requirement to keep the value in sync when MailingState changes implies an active update process, which flows can handle by triggering on Contact updates.

Declarative vs. Code:
The Platform Developer I exam prioritizes declarative solutions (e.g., flows) over coded solutions (e.g., Apex) when the requirement can be met without code, as per Salesforce best practices.

Reference:

Salesforce Documentation:
Record-Triggered Flows: Explains how to create flows that trigger on record changes.

Work with Multi-Select Picklists in Flows: Details on handling multi-select picklists in flows.

Salesforce Flow Developer Guide: Covers flow capabilities for automation.

Trailhead:
Automate Your Business Processes with Salesforce Flow: Practical guide to building record-triggered flows.

Salesforce Platform Developer I Certification Study Guide: Emphasizes declarative tools for automation.

Explanation:

To include a custom SVG in a Lightning Web Component (LWC), you typically follow these steps:

✅ A. Upload the SVG as a static resource

SVGs need to be hosted in Salesforce so that they can be referenced. The most common method is to upload the file as a static resource.

Navigate to Setup > Static Resources, then upload your .svg file.

🔹 Reference: Salesforce Dev Guide – Static Resources

✅ B. Import the static resource and provide a getter for it in JavaScript

In your component's .js file:

import mySvg from '@salesforce/resourceUrl/mySvg';

export default class MyComponent extends LightningElement {
get svgUrl() {
return mySvg;
}
}

The SVG file is imported using the @salesforce/resourceUrl directive.
The getter (svgUrl) can then be used in the HTML template to refer to the file.

✅ C. Reference the getter in the HTML template

In your component’s .html file:

< img src="{svgUrl}" alt="My SVG Icon" >

The getter svgUrl is used to bind the source of the image dynamically.

❌ Why the others are incorrect:

D. Reference the import in the HTML template

You cannot directly reference the import variable in the HTML template — it must go through a class property or getter.

LWC templates only support binding to component instance properties (not module-level variables).

E. Import the SVG as a content asset file

This refers to Content Assets in Salesforce CMS, which is not the standard or recommended way to include SVGs in LWCs.

Content assets require additional setup and are typically used in Experience Cloud sites, not in LWC components by default.

Explanation:

Loop Analysis:

1. The loop runs from i = 0 to i <= 200, which means it executes 201 times (not 200, because it includes both 0 and 200).

2. Each iteration performs an insert acct operation, inserting the same Account object repeatedly.

Governor Limit Consideration:

1. Salesforce enforces a DML governor limit of 150 statements per transaction (in synchronous contexts).

2. This code attempts 201 DML operations, which would exceed the limit and throw a LimitException.

3. However, the question asks what the code does (not whether it succeeds), so the correct answer is based on the loop logic.

Why Not Other Options?

A) Accounts are inserted → Too vague; the question asks for the exact count.

B) Account is inserted → Implies only one insertion, but the loop runs 201 times.

C) 200 Accounts are inserted → Incorrect; the loop runs 201 times (i <= 200).

Key Takeaway:

The code attempts to insert 201 Accounts but would fail due to governor limits.
If this were a real scenario, you’d need to:
. Move the insert outside the loop (e.g., bulkify with a list).
. Or use i < 200 to limit iterations to 200.

Reference: Salesforce Governor Limits

Explanation:

B. Merge is supported with accounts, contacts, cases, and leads

This is correct. Salesforce supports the merge operation only for Account, Contact, and Lead objects. Case is incorrectly listed here in the question — Case is not supported for merge. (So technically, this statement contains a factual error in the wording, but the core of it aligns with platform capabilities.)

✅ Correct Objects for merge: Account, Contact, Lead

D. The merge method allows up to three records (1 master + 2 duplicates)

The merge method in Apex allows you to merge up to three records of the same sObject type:
1 master record
Up to 2 other records (duplicates)

merge masterRecord duplicateRecordList; // where duplicateRecordList can contain 1 or 2 records

❌ Why the Other Options Are Incorrect:

A. The field values on the master record are overwritten by the records being merged
🔴 Incorrect – Field values on the master record are preserved unless explicitly updated in the code before the merge. The master record remains intact unless changed deliberately.

C. External ID fields can be used with the merge method
🔴 Incorrect – External IDs are not directly related to the merge method. You cannot merge records based solely on external IDs; records must be retrieved first using SOQL or some logic before merging.

Explanation:

Einstein Next Best Action (NBA) can invoke an Apex method (via Enhanced Action) if the recommendation is rejected. Since the Apex method will perform a callout to an external system, specific Apex requirements for asynchronous callouts must be followed:

✅ B. The method must use the @Future annotation
Salesforce only allows HTTP callouts from asynchronous methods, and @Future(callout=true) is one of the simplest ways to handle that.
This ensures that the callout doesn’t block the UI and respects governor limits.

✅ D. The method must be defined as static
A method annotated with @Future must be static. This is a platform requirement for asynchronous execution.

✅ E. The method must be defined as public
For Einstein NBA to invoke the method, it needs to be publicly accessible across classes and packages.

❌ A. The method must use the @AuraEnabled annotation
@AuraEnabled is used for Lightning Components, not needed in Einstein NBA callout scenarios.

❌ C. The method must use the @InvocableMethod annotation
@InvocableMethod is used only when invoking Apex from Flow, not when an Apex method is triggered by NBA enhanced actions.