Salesforce-Platform-Developer Practice Test Questions

Explanation:

1. A. Callouts to external systems are not executed when debugging a flow. ✅
When running a flow in debug mode, Salesforce prevents real external callouts (like HTTP requests) from being made. This ensures debugging doesn’t trigger real integrations or external changes.
Instead, the system simulates the callout.

2. D. DML operations will be rolled back when the debugging ends. ✅
Any database changes (create, update, delete) made during a debug run are not saved to the org. Salesforce automatically rolls them back after debugging ends.
This protects real data and prevents test runs from polluting records.

3. B. Clicking Pause or executing a Pause element closes the flow and ends debugging. ❌
Debug mode does not support Pause elements. If the flow contains a Pause, you cannot debug it. The system will give a message instead of ending the flow abruptly.

4. C. Input variables of type record cannot be passed into the flow. ❌
Record-type input variables can be passed in during debugging. You can select specific records to pass as inputs when you run/debug the flow.

Reference:
Salesforce Help: Debug flows in Flow Builder
Trailhead: Build Flows with Flow Builder

✅ Final Answer: A and D

Explanation:

You need a Visualforce page to show a list of contacts owned by the current user, and it should be simple with no extra work. Here’s why each option fits or doesn’t:

Standard List Controller (A): This is built for showing lists of records, like multiple contacts. It handles everything you need, like sorting and paging, and you can easily filter it to show only the contacts the current user owns. It’s the simplest option, which matches the goal of avoiding unnecessary work.

Standard Controller (B): This is for working with just one record, like a single contact. Since you need a list, this won’t work.

Lightning Controller (C): This doesn’t exist for Visualforce pages. Visualforce uses standard or custom controllers, while Lightning components have their own controllers. Since this is a Visualforce page, this option doesn’t apply.

Custom Controller (D): You could write your own controller to get the contacts, but it takes more effort to set up the list and features like paging. The question asks for minimal work, so this isn’t the best choice.

Why Standard List Controller?
It’s the easiest way to show a list of contacts, and you can filter it to only show the current user’s contacts. It works perfectly when the page is added to a Lightning page, and it keeps things simple.

Reference:
Salesforce Documentation: Standard List Controllers (explains how they work with lists of records).
Salesforce Documentation: Using Visualforce in Lightning Experience (confirms Visualforce works in Lightning pages).

Explanation:

The code snippet shows a Lightning Web Component (LWC) using @wire to call an Apex method named fetchOpportunities from the OpportunitySearch class. The @wire service is used to read Salesforce data reactively. For an Apex method to be compatible with the @wire service, it must adhere to specific criteria.

Why A is Correct: The (cacheable=true) attribute is a mandatory requirement for an Apex method to be called via the @wire service. This directive tells the framework that the method is a read-only operation, which allows the framework to cache the results and manage its reactivity efficiently. This is a key difference between @wire and imperative calls.

Why D is Correct: This is a direct consequence of using (cacheable=true). A cacheable method must be a read-only operation. It cannot perform Data Manipulation Language (DML) operations such as insert, update, delete, or undelete. It also cannot modify the data within the result set before returning it, as this would violate the principle of the method being idempotent (returning the same result for the same input every time).

Why E is Correct: The @AuraEnabled annotation is fundamental. It makes an Apex method accessible from any Lightning code, including both Aura Components and Lightning Web Components. Without this annotation, the client-side code cannot see or call the method.

Why B is Incorrect: The (continuation=true) attribute is used for making long-running callouts to external systems from Apex. It is part of the Continuation framework and is completely unrelated to the @wire service or querying database records for display in an LWC.

Why C is Incorrect: The @InvocableMethod annotation is used to expose an Apex method for use in Process Builder, Flow, or the REST API. While an Apex method can technically have both @AuraEnabled and @InvocableMethod annotations, @InvocableMethod is not required for the method to be available to a Lightning Web Component via @wire or imperative calls. The @AuraEnabled annotation is the one that is specifically required for this context.

Reference:
Salesforce Developer Documentation: Call Apex Methods

Specifically, the documentation states: "To use the @wire service to call an Apex method, annotate the Apex method with @AuraEnabled(cacheable=true)." It also clarifies that "Apex methods are read-only and don’t mutate data when called via the @wire service."

Explanation:

🟢 Correct Answer: A. An External ID field can be used to reference an ID from another external system.
This is a primary use case for External IDs. When you are integrating Salesforce with an external system, you often need to store the unique identifier from that system on the Salesforce record. By marking a field as an External ID, you can use its value to upsert records (update existing records or insert new ones) without having to know the Salesforce ID (the 15 or 18-character ID). This is crucial for data loading and integration scenarios where the external system's ID is the key to matching records.

🟢 Correct Answer: D. An External ID is indexed and can improve the performance of SOQL queries.
Salesforce automatically creates an index on fields marked as an External ID. An index is a data structure that improves the speed of data retrieval operations on a database table. Therefore, using an External ID in the WHERE clause of a SOQL query will be significantly faster than querying a non-indexed field. This is particularly important for large data sets, as it helps avoid timeouts and improves overall application performance. While other fields can be indexed, the External ID designation is a simple way to ensure a field is indexed for this purpose.

🔴 Incorrect Answer: B. An External ID can be a formula field to help create a unique key from two fields in Salesforce.
Reasoning: This is incorrect because a field designated as an External ID must be a writable field type, such as Text, Number, or Email. Formula fields are read-only and their values are calculated dynamically at runtime. As such, they cannot be used for matching or upserting records via an external key, which is a key function of an External ID. You cannot select the "External ID" checkbox for a formula field when you are creating or editing the field in Salesforce.

🔴 Incorrect Answer: C. An External ID can be used with Salesforce Mobile to make external data visible.
Reasoning: While you can use External IDs in some integration scenarios with Salesforce Mobile, the primary function of an External ID is for record matching and data synchronization, not for making external data visible. The Salesforce feature specifically designed to display data from external systems in real-time, within the Salesforce user interface, is Salesforce Connect. This feature uses External Objects and External Data Sources to present the data, which is a different concept from a field's External ID attribute.

Reference:
For further information on External IDs and their capabilities, you can refer to the official Salesforce documentation on "Custom Field Attributes" and "External IDs." This resource details the supported field types for External IDs and explains their purpose in data integration and performance.
Source: Salesforce Help: Custom Field Attributes

Explanation:

A. force:data:bulk:upsert ✅
This command uses the Bulk API to insert or update large amounts of data into a sandbox.
It’s especially useful when working with big data volumes, like thousands of records.

C. force:data:tree:upsert ✅
This command lets you import data in a structured format, often using JSON files.
It’s great when you need to load related records (like Accounts with related Contacts) because it preserves relationships.

B. force:data:object:upsert ❌
There’s no such command in the Salesforce CLI (sfdx). Looks like a trick option.

D. force:data:async:upsert ❌
Also not a valid CLI command. Another distractor.

Reference:
Salesforce CLI Command Reference – force:data

✅ Final Answer: A and C

Explanation:

To choose the right field, we need to understand the business need and how Salesforce relationships work. UC wants multiple Accounts to share one default pickup address, so one Global Address record could be linked to many Accounts. Let’s look at each option:

Option A: Master-Detail field on the Account object to the Global Address object
In a Master-Detail relationship, the child object (Account) would depend on the parent (Global Address). This means:
→ Each Account could only link to one Global Address (which is fine).
→ If the Global Address is deleted, all related Accounts would also be deleted because Master-Detail relationships enforce cascading deletion.
→ Deleting Accounts just because a shared address is removed doesn’t make sense for this business need. Accounts are independent records and should exist even if the Global Address is deleted.
→ This option is not efficient because it creates a strict dependency that could cause problems.

Option B: Master-Detail field on the Global Address object to the Account object
Here, Global Address would be the child, and Account would be the parent. This means:
→ Each Global Address could only link to one Account.
→ The business need is for multiple Accounts to share one Global Address, so this setup wouldn’t work. You’d need a separate Global Address record for every Account, which defeats the purpose of a shared default pickup address.
→ This option doesn’t support the requirement.

Option C: Lookup field on the Account object to the Global Address object
In a Lookup relationship, the Account object would have a field that points to a Global Address record. This means:
→ Each Account can link to one Global Address (the default pickup address).
→ One Global Address can be linked to many Accounts, which perfectly matches the requirement for multiple Accounts to share a default pickup address.
→ If a Global Address is deleted, the Accounts remain unaffected, with the lookup field becoming blank. This is safer and more logical for Accounts, which are independent records.
→ This is the most efficient model because it supports the business need (shared addresses) without unnecessary restrictions.

Option D: Lookup field on the Global Address object to the Account object
Here, the Global Address object would have a field pointing to an Account. This means:
→ Each Global Address could only link to one Account.
→ This doesn’t allow multiple Accounts to share one Global Address, which goes against the requirement.
→ You’d need multiple Global Address records for each Account, making the process less efficient.

Why Lookup Field on Account to Global Address?
The Lookup field on the Account object to the Global Address object (Option C) is the best choice because:
→ It allows many Accounts to reference the same Global Address record, meeting the need for a shared default pickup address.
→ It’s flexible and doesn’t impose strict rules like a Master-Detail relationship, so Accounts remain independent.
→ It’s efficient, requiring only one Global Address record for multiple Accounts, which reduces data duplication and supports UC’s goal of lowering shipping costs by streamlining address management.

Reference:
Salesforce Documentation: Relationship Types (explains Lookup vs. Master-Detail relationships).
Salesforce Documentation: Custom Objects (covers creating custom objects like Global Address).

Summary:
The developer should add a Lookup field on the Account object to the Global Address object (Option C). This setup lets multiple Accounts share one Global Address, keeps Accounts independent, and supports UC’s goal of efficient shipping with minimal complexity.

Explanation:

Validation rules are enforced by the Salesforce platform at the database level. When a validation rule fails during a DML operation (like insert, update), Salesforce throws a system-defined DmlException. The standard behavior of Visualforce, when coupled with a custom controller, is to automatically handle these exceptions and display any validation rule errors (or other platform errors) through the component.

Let's break down why this is the correct answer and why the others are not:

Why B is Correct: The component is specifically designed to display all information, confirmation, and error messages that are generated by the Salesforce platform. This includes validation rule violations, required field missing errors, duplicate rule violations, and other DML exceptions. By simply including this tag on your Visualforce page, any error that occurs during a DML operation in the controller's method will be displayed automatically to the user without any need for additional code to catch and parse the exception.

Why A is Incorrect: While you could create a custom controller attribute (e.g., a String variable) and manually set an error message in a catch block, this is entirely unnecessary and error-prone. The platform already provides the error messages automatically. Manually doing this would require catching the exception, parsing the error message, and then redirecting it to the page, which is what does for you automatically.

Why C is Incorrect: Using a try/catch block is part of the process, but it is not the complete solution on its own. If you simply catch the DmlException, the error is caught by your code but is never displayed to the user unless you explicitly take the error messages from the exception and add them to the page. The component is the standard, built-in mechanism for displaying those errors. A custom exception class is not needed for standard validation rule errors.

Why D is Incorrect: The choice of DML method (Database.upsert(), insert, etc.) does not change how validation rule violations are handled. All DML operations will respect and enforce validation rules. While Database.upsert() allows for partial success processing in bulk operations, for a single record save operation on a Visualforce page, its behavior regarding error handling and display would be the same as a standard upsert statement. The key to displaying the error remains the presence of the component.

Reference:
Visualforce Component Reference: apex:pageMessages - This component displays all messages that were generated for all components on the current page.

The underlying mechanism is that when a DML exception occurs, the platform adds the error messages to the ApexPages message list. The component simply renders these messages.

Explanation:

C. Use a before-save Apex trigger on the Lead object to validate the email address and display an error message if it is invalid.
A before-save Apex trigger is the most effective solution for this requirement. It executes before the record is saved to the database, allowing you to validate data and prevent the record from being created or updated if the validation fails. Triggers can display a user-friendly error message directly on the page, which is a powerful way to provide immediate feedback to the user. This approach also works for all methods of record creation, including the user interface, data imports, and APIs, ensuring the validation is applied universally. This method is an excellent way to add an "additional layer of validation" to an existing validation rule.

❌ Why the Other Options Are Incorrect?

A. Submit a REST API Callout with a JSON payload and validate the fields on a third-party system.
While you could perform an API callout from Apex, doing so in a before-save trigger is not allowed. Callouts must be made from asynchronous Apex (future methods or queueable Apex) or after-save triggers, and they don't block the DML operation. You can't use an API callout to prevent a save from happening.

B. Use an Approval Process to enforce the completion of a valid email address using an outbound message action.
An Approval Process is designed to require a record to be approved before it can be finalized. It's not a direct data validation tool that prevents a record from being saved. An Outbound Message is an action that sends data to an external system, but it cannot be used to display an error message on the Salesforce record page or prevent the record from being saved.

D. Use a custom Lightning web component to make a callout to validate the fields on a third-party system.
This solution is not comprehensive enough. A Lightning Web Component (LWC) would only enforce the validation when a user is creating a lead via that specific component. It would not apply if a lead is created through a different method, such as a standard page layout, a data import, or an API call. For universal validation, a trigger is a better choice.

Explanation:

A. ✅

This is the correct way:
Uses (required for embedding in Visualforce).
Extends ltng:outApp (necessary to support Lightning Out).
Declares the dependency properly.
✅ Correct Answer.

B. ❌
You cannot extend ltng:outApp from a component. That’s only valid for applications.
❌ Invalid.

C. ❌
Same issue: a component can’t directly be declared as a dependency provider for Visualforce embedding.
❌ Invalid.

D. ❌
It’s missing extends="ltng:outApp", which is required for Lightning Out with Visualforce.
❌ Incomplete.

Reference:
Salesforce Docs – Use Lightning Components in Visualforce Pages

✅ Final Answer: A. Option A

Explanation:

To satisfy this requirement, a developer needs to retrieve data from an external system in real time and display it in a multi-screen flow. A flow screen component is the primary tool for displaying a user interface within a flow. This component needs a mechanism to get the data from the external system. An Apex controller is the standard way to handle complex logic, including making callouts to external web services, and passing that data back to a UI component. The flow would call the screen component, which in turn would use the Apex controller to make the real-time callout to the external order management system and retrieve the list of order numbers and dates to display on the screen.

Why the Other Options Are Incorrect?

B. An Apex REST class: An Apex REST class is used to expose Salesforce data to an external application, acting as a web service. This is the opposite of what's needed here, as the requirement is to get data from an external system, not send it to one.

C. An outbound message: An outbound message is a workflow action that sends a message to an external system. Like the Apex REST class, this is used for sending data out of Salesforce, not for receiving it in real time to display on a screen.

D. An invocable method: An invocable method can be called from a flow, but it's used for performing specific business logic or actions. While an invocable method could theoretically make a callout, the standard pattern for a screen component that needs to retrieve and display data is to use a dedicated Apex controller. An invocable method is not designed for the UI data binding that a screen component requires to display a list.