SalesForce PDII - Questions & Answers

When a Visualforce page is slow because it attempts to load a massive dataset all at once, the bottleneck is often the time taken by the controller constructor to query and process those records before the page can even begin to render. Lazy Loading (Option B) is a strategy where the developer avoids loading all data during the initial page initialization.

Instead of querying 10,000 records in the constructor, the developer can load only the structural elements of the page first. Then, using an action method (triggered by <apex:actionFunction> or a window.onload
script), the data is fetched in the background. This allows the user to see the page layout immediately while the data "populates" shortly after. This significantly improves the Time to First Byte (TTFB) and the perceived performance of the page.

Option A (transient) is excellent for reducing the View State size and speeding up postbacks (button clicks), but it does not inherently speed up the initial load time of a large dataset.
Option C (JavaScript processing) can help but doesn't solve the data retrieval bottleneck.
Option D (actionPoller) is used for periodic updates and is not an efficient way to load an initial large dataset. Lazy loading ensures that the "heavy lifting" is decoupled from the initial page load, providing a more responsive experience.

The "Customer Community Plus" license is distinct because it supports advanced sharing features, including Apex Managed Sharing. In a Private sharing model, a standard community user can only see records they own or those shared with them via the role hierarchy (if applicable). Since the requirement involves granting access based on a complex relationship defined in a junction object , standard sharing rules are insufficient because they cannot "walk" the relationship of the junction object to determine access.

Apex Managed Sharing (Option B) allows a developer to bridge this gap. A trigger can be written on the junction object. When a relationship is created between a Contact (Community User) and an Account (Department), the trigger can insert a record into the AccountShare table (or the share table of the container object). This share record explicitly grants the User 'Read' access to the related records.

Option D is an "anti-pattern" because using without sharing to bypass security is a security risk and doesn't actually grant record access for standard platform features; it only hides the restriction within that specific
page. Option A and C are UI-level solutions and do not address the underlying record-level security (sharing) required for a Private OWD model. Apex Managed Sharing provides a robust, programmatic way to enforce complex, data-driven security requirements in a Community environment.

Salesforce has a strict rule: You cannot perform a synchronous web service callout after performing a DML operation in the same transaction. In the provided code, the insert operations (DML) occur first, creating
"uncommitted work" in the database. When the code then tries to execute makeRestCallout, the platform throws the error to prevent a long-running callout from holding database locks open.

To resolve this, the callout must be moved to its own separate transaction. The most straightforward way to do this is to change the callout method to an @future(callout=true) method (Option D). When an @future method is called, the request is queued and executed in a new, independent transaction with its own governor limits. This decouples the database "work" from the external "callout."

Option C is incorrect because simply moving the line doesn't change the transaction context.
Option B (removing savepoints) doesn't help because the DML itself is the blocker.
Option A (@InvocableMethod) is used for Flow/Process Builder and doesn't inherently solve the transaction boundary issue. Using an @future method (or a Queueable class) is the standard platform-aligned solution for this error.

Salesforce enforces a strict restriction: actual network callouts are prohibited during unit tests. This is to ensure that tests are deterministic, fast, and do not rely on the availability or state of external third-party systems. When the testing engine encounters a System.Http.send() or a web service call without a mock, it throws the error: "Methods defined as TestMethod do not support Web service callouts."

To resolve this, the developer must provide a mock implementation. By using Test.setMock() (Option D), the developer instructs the Apex runtime to intercept any callouts and return a predefined response instead of attempting a real connection. The mock class must implement either the HttpCalloutMock interface (for REST) or the WebServiceMock interface (for SOAP).

Furthermore, the call to the mock and the callout method should be wrapped in Test.startTest() and Test.stopTest().

Test.startTest(): Resets governor limits, providing a fresh context for the specific logic being tested.

Test.stopTest(): Forces any asynchronous processing (often used in callouts, such as @future or Queueable) to complete before the next line of code executes.

In the provided code, Test.setMock() must be called before CalloutUtil.sendAccountUpdate for the platform to know which mock to use. Once Test.stopTest() is reached, the mock response is processed, the checkbox is updated, and the subsequent SOQL query and assertion will correctly see the updated data.
Option A is a poor practice because it skips the logic entirely, resulting in 0% code coverage for the integration logic.

The Visualforce View State is a hidden form field that maintains the state of the page (including controller variables) between server requests. Salesforce imposes a strict 135KB limit on the View State. When a page handles large amounts of 10data--such as large lists of records or complex objects--the serialized size of the controller variables can easily exceed this limit, resulting in a runtime error for the user.

To correct these errors, the developer should use the transient keyword (Option B). Marking a variable as transient prevents it from being serialized into the View State. This is the standard best practice for any data that does not need to be maintained across "postbacks" (actions that refresh the page or part of the page).

Common candidates for the transient keyword include:

Large lists of records retrieved for display only.

Temporary variables used for calculations during a single request.

Summary data that can be easily re-queried if needed.

Option D relates to security, not performance.
Option C (private variables) does not exclude variables from the View State; only static and transient variables are excluded. Option A relates to SOQL governor limits,
which are independent of the View State size. By judiciously using transient, the developer keeps the page weight low and ensures a smooth user experience in production environments with real-world data volumes.

In Salesforce Apex triggers, choosing the correct context (before vs. after) is critical for performance and data integrity. When the business requirement involves creating or modifying related records (records other than the one that fired the trigger), an after trigger is the platform-standard choice.

An after update trigger (Option C) is ideal here because it ensures that the Case record has been successfully validated and saved to the database (obtaining a valid timestamp and state) before the child Engineering_Review__c record is generated. Furthermore, an after trigger provides access to the read-only Trigger.new and Trigger.old maps, which contain the final field values after system validation rules and flows have run. Performing DML operations to insert a new object within a before trigger is technically possible but discouraged, as it can lead to issues if the primary record fails a subsequent system validation, potentially leaving orphaned data or causing complicated rollback scenarios.

Options A and D are incorrect because "upsert" is not a valid trigger event; the valid events are insert, update, delete, and undelete. Option B is incorrect because before triggers should primarily be used for updating fields on the same record that initiated the trigger to avoid redundant DML calls. Therefore, an after update trigger provides the most stable and scalable context for cross-object record creation.