PDI Practice Test Questions

Explanation:

Universal Containers needs to build a guided scripted process that includes calling an external REST API to retrieve data. The ideal solution should be declarative for user interaction and programmatic for integration with the ERP system. This requirement can be met by combining Flows with Invocable Apex methods.

🔹 A. Flow (✔ Correct)
Screen Flows are perfect for guiding users through step-by-step processes like a customer onboarding script.
The flow can include screen elements, decisions, and actions like calling Apex code.
It improves the user experience for sales reps by presenting structured and interactive steps.

🔹 D. Invocable Method (✔ Correct)
Invocable Apex methods are callable from Flows, making them the best choice to perform backend logic.
Used here to perform a callout to the ERP REST API to check for existing customer data.
The flow can then display the returned data directly to the user.

❌ Why the Other Options Are Incorrect:

B. Future Method
Future methods are for asynchronous processing and cannot be called from a Flow or return data back to the Flow.
They are not suitable for real-time API responses needed during user interaction.

C. Trigger
Triggers are used for backend automation on record changes, not for interactive UI flows or external API calls initiated by user actions.
Inappropriate here because the call to the ERP system is based on user-driven flow logic, not record insert/update.

Explanation:

Salesforce offers multiple ways to execute Apex tests in an org, supporting both UI-based and programmatic testing. The best options depend on whether you prefer manual test execution or automation as part of CI/CD pipelines.

🔹 A. Tooling API (✔ Correct)
The Tooling API allows developers to run Apex tests programmatically, making it ideal for automated test execution in CI/CD pipelines.
You can execute tests and retrieve test results, code coverage, and debug logs using this API.
Commonly used in integrations with tools like Jenkins, GitHub Actions, or Salesforce DX.

🔹 B. Developer Console (✔ Correct) The Developer Console provides a point-and-click UI to run specific test classes, methods, or all tests in an org.
It also shows code coverage, logs, and test results, which helps in debugging and validation.
Ideal for quick testing and diagnostics during development.

Why Not the Other Options?

❌ C. Bulk API
The Bulk API is meant for handling large data volumes, such as mass imports, updates, or deletions.
It does not support test execution.

❌ D. Metadata API
The Metadata API is used to deploy or retrieve metadata like Apex classes and objects.
It doesn’t offer functionality to run or validate tests directly.

Explanation:

The Lightning Component framework (now primarily referring to Lightning Web Components, and previously Aura Components) is the foundational technology for building and customizing the user interface within Salesforce's Lightning Experience.

C. Lightning Pages: This is the primary and most direct use case. Developers create custom Lightning components that can then be easily dragged and dropped onto Lightning Pages (such as Home Pages, Record Pages, and App Pages) using the Lightning App Builder. These components extend the standard Salesforce UI and provide custom functionality.

Let's look at why the other options are less accurate:

A. Customized JavaScript buttons: These are primarily a feature of Salesforce Classic and often rely on specific Classic JavaScript APIs. While Lightning Components use JavaScript, the framework itself is not primarily for building these legacy button types.
B. Salesforce Classic user Interface pages: The Lightning Component framework is designed for the Lightning Experience UI. Salesforce Classic pages are typically built using Visualforce or standard page layouts.
D. Salesforce integrations: Salesforce integrations involve connecting Salesforce with external systems (e.g., via APIs, middleware). While a Lightning component might display data fetched from an integration, the Lightning Component framework itself is a UI framework, not an integration framework. The actual integration logic (making callouts, processing responses) is typically handled by Apex.

Explanation:

When building modern, responsive applications that support touch events and are designed for stateful client environments like mobile or desktop browsers, developers should use frameworks designed for rich, client-side interactivity. Both Aura Components and Lightning Web Components (LWC) are purpose-built by Salesforce for this use case.

✅ A. Aura Components
Aura is a component-based framework designed for building responsive UIs.
It supports client-side controllers, event-driven architecture, and touch interactions, making it well-suited for mobile-ready apps.
It maintains state in the browser, supporting stateful client execution.

✅ C. Lightning Web Components (LWC)
LWC is Salesforce’s modern web standards–based framework.
It supports full event handling, touch interaction, and responsive layouts, ideal for mobile and desktop experiences.
It's also lightweight and more performant compared to Aura.

❓ Why Not the Other Options?

❌ B. Visualforce Components
Visualforce is server-rendered and doesn’t natively support client-side responsiveness or touch event handling.
It lacks the real-time client interactivity that Aura and LWC provide.

❌ D. Visualforce Pages
Like Visualforce Components, these pages rely on page reloads and are not stateful on the client side.
You would need significant custom JavaScript to mimic responsive and touch-capable behavior, which is not efficient or scalable.

Explanation:

When working with record types in Apex, especially to determine the default record type for the current user on a specific object (like Opportunity), the correct approach is to use the Describe metadata capabilities provided by Salesforce.

✅ Why Option B is Correct:
Opportunity.SObjectType.getDescribe() gets the describe result for the Opportunity object.
.getRecordTypeInfos() returns a list of RecordTypeInfo objects.
Each RecordTypeInfo has a method .isDefaultRecordTypeMapping() that returns true for the current user's default record type.
This approach dynamically respects user-specific profile and permission settings.

❓ Why Not the Other Options?

❌ A. Query the Profile and use profile.Opportunity.getDefaultRecordType()
This syntax is invalid. The Profile object cannot directly return the default record type for an object.
Record type visibility and defaults are managed at the Profile + Object level, and not directly queryable this way in Apex.

❌ C. Use Schema.userInfo.Opportunity.getDefaultRecordType()
There is no such method or class as Schema.userInfo.Opportunity.getDefaultRecordType() in Apex.
This is an incorrect reference to metadata methods.

❌ D. Create the Opportunity and check opportunity.recordType
This approach is not reliable because the record type field will be null unless explicitly set.
It’s also inefficient—you shouldn’t create a record just to check what the default type would have been.

Explanation:

Why Option B?

Trigger + Handler Pattern:

The most scalable and maintainable approach is to:

Create a trigger on the Request__c object.
Call the existing RequestLogic class from the trigger to enforce business rules.
Example Implementation:

// Trigger
trigger RequestTrigger on Request__c (before insert) {
if (Trigger.isBefore && Trigger.isInsert) {
RequestLogic.preventInvalidRequests(Trigger.new);
}
}

// RequestLogic.cls
public class RequestLogic {
public static void preventInvalidRequests(List newRequests) {
for (Request__c req : newRequests) {
if (/* invalid conditions */) {
req.addError('Creation not allowed due to system conditions.');
}
}
}
}

Explanation:

To investigate and troubleshoot performance issues—especially during custom page loads—the most appropriate and direct tool provided by Salesforce is the Developer Console.
The Developer Console offers powerful diagnostic features that help developers identify bottlenecks such as:

Slow SOQL queries
Inefficient Apex execution
Expensive view state size
Trigger recursion or bulk issues
JavaScript execution and network latency (when used alongside browser tools)

🔍 What You Can Do With Developer Console:

Use the "Execution Overview" tab to track what took the most processing time.
Use the "Query Plan Tool" to optimize SOQL queries.
Monitor logs in real-time to trace errors and governor limit usage.
Use the "View State" tab when working with Visualforce pages to analyze data payloads.

❓ Why Not the Other Options?

❌ A. AppExchange
AppExchange is a marketplace for installing Salesforce apps but is not a diagnostic tool for performance issues.

❌ B. Salesforce CLI
CLI is great for automation, scripting deployments, and managing orgs, but not ideal for real-time performance debugging.

❌ C. Visual Studio Code IDE Useful for code writing, testing, and deployment, but doesn't offer real-time performance tracing for page loads within the org.

Explanation:

In Apex, the default sharing behavior of a class is to inherit the sharing context of the caller, unless explicitly defined otherwise using the with sharing or without sharing keywords.

In the provided code snippet:

public class myClass {
public void myMethod() {
// implementation
}
}

There is no explicit sharing declaration, so Salesforce assumes neutral context — also known as "inherited sharing".

🔍 What This Means:

If the calling class or trigger has with sharing, then myMethod() will enforce sharing rules.
If the calling code has without sharing, then myMethod() will not enforce sharing rules.
This provides flexibility but can lead to unintentional data access if not documented or controlled properly.

❓ Why Not the Other Options?

B. Sharing rules will be enforced for the running user
❌ Incorrect unless the class is explicitly declared with sharing.

C. Sharing rules will be enforced by the instantiating class
❌ Misleading — instantiating a class does not dictate sharing context; it's the caller’s context that matters.

D. Sharing rules will not be enforced for the running user
❌ Also incorrect unless without sharing is explicitly used.

Explanation:

Why Full Sandbox?
A Full Sandbox is the only Salesforce org that provides a complete replica of your Production org, including:

All data (standard/custom objects, records).
Configuration (metadata, customizations, apps).
User records (with passwords reset for security).
Use Case: Ideal for testing, training, or disaster recovery with real-world fidelity.

Why Not Other Options?

A. Developer Pro Sandbox:
Contains metadata only (no production data).

B. Partial Copy Sandbox:
Includes metadata + a subset of data (defined by sandbox templates).

C. Production:
Your live org—not a copy.

Explanation:

A. An invocable method: A Flow can directly call an Invocable method in Apex. This Invocable method can then contain the logic to make a real-time callout to the external order management system (via a REST endpoint, for example). Once the data is retrieved from the external system, the Invocable method can return that data to the Flow, which can then display it on a screen element to the agent. This is the standard and most efficient way to achieve real-time external data retrieval and display within a multi-screen Flow.

Let's look at why the other options are not suitable:

B. An Apex REST class: An Apex REST class is used to expose Salesforce functionality as a web service that external systems can call into Salesforce. It's for inbound integrations to Salesforce, not for Salesforce to call out from a Flow to an external system.
C. An outbound message: An outbound message is a declarative way to send information from Salesforce to an external system. It's typically asynchronous and unidirectional (Salesforce sends data out), and it cannot retrieve data from an external system in real time for display in a Flow.
D. An Apex Controller: While an "Apex Controller" (a generic term for an Apex class that controls logic) would be involved in making the actual callout, the specific type of Apex method that a Flow can directly invoke and get data back from is an Invocable Method. Simply calling it an "Apex Controller" is too broad and doesn't specify the direct integration point for Flows.