Platform Developer Certification Maintenance (Winter '26)

 Maintain Your Platform Developer Certification for Winter ‘26

Handle Large External Service Callouts and Payloads Without Hitting Apex Heap Limits

Working with large amounts of data in Apex can quickly push you up against heap size limits, especially when you need to transfer files or binary payloads to or from external systems. This release introduces a more efficient process for managing large callouts through External Services. Instead of loading binary data directly into the Apex heap, External Services now uses pointers to ContentDocument object IDs.

This means you can upload or download binary files up to 16 MB without blowing through heap limits, significantly improving reliability for data-heavy integrations. For example, a developer integrating Salesforce with a digital asset management system can now transfer large images or PDFs without running into Apex governor limits. And because this process uses ContentDocument as the storage mechanism, the files remain accessible within Salesforce for auditing or reprocessing.

Use this approach when you need to work with large files that don’t require in-memory processing in Apex. If you must parse or transform the file contents in Apex, consider doing so in smaller chunks to avoid hitting heap limits.

Use Access Modifiers on Abstract and Override Methods

Starting with API version 65.0, Salesforce enforces the use of explicit access modifiers on abstract and override methods. You must declare these methods as protected, public, or global — the private modifier is not allowed, because it would block implementing classes from accessing the method.

This change improves code clarity and prevents developers from accidentally writing methods that cannot be implemented by subclasses. If you omit the access modifier or use an unsupported one, you’ll see a compilation error.

Review your Apex classes before upgrading their API version to 65.0 or later, and update any abstract or override methods to include the correct access modifier. This will ensure your code continues to compile and function as expected.

Elevate Third-Party Scripts with LWS Trusted Mode

Lightning Web Security (LWS) and Lightning Locker protect your Salesforce environment by isolating components and preventing unauthorized access to the global namespace. However, these security measures can sometimes block business-critical third-party libraries that require global access to function properly.

LWS Trusted Mode allows developers to safely bypass these restrictions for code that they trust. By marking a component as trusted, you can allow it to run third-party scripts without LWS or Locker limitations. This is particularly useful for integrating analytics libraries, advanced visualization frameworks, or other scripts that need direct access to the browser’s global context.

Only enable LWS Trusted Mode for libraries that are vetted and safe, as this opens up a broader attack surface. Follow Salesforce security guidelines and your organization’s governance process before enabling trusted mode in production.

Explore New and Changed LWC Modules

Salesforce continues to expand Lightning Web Components (LWC) capabilities, giving developers more flexibility and power when building apps. Here’s what’s new and updated for this release:

New Modules

• lightning/graphql – Use this module to fetch data with the GraphQL API for UI API–enabled objects. It respects object- and field-level security for the running user and replaces the deprecated lightning/uiGraphQLApi.
  
  • Supports optional fields and dynamic query construction.
    
  • Recommended for all new GraphQL-based data fetching.
    
• lightning/omnistudioPubsub – Allows your custom components to communicate with FlexCards or OmniScripts using a publish-subscribe mechanism.
  
  • Ideal for embedding OmniStudio wrapper components and enabling seamless interaction between components.
    

Changed Modules

• lightning/conversationToolkitApi – Adds a new method:
  
  • inactivateConversation(recordId) – Inactivates a conversation record by ID. Returns a promise that resolves to true or rejects if there’s an error.
    
• lightning/uiGraphQLApi (Deprecated) – This module, its wire adapter, and refreshGraphQL() function are now deprecated.
  
  • Action: Migrate to lightning/graphql to ensure ongoing support and access to new functionality.
    

Use LWC Components for Local Actions in Screen Flows

Screen flows are powerful tools for guiding users through business processes, but historically they were limited in how they could interact with the browser. With this release, you can now use Lightning Web Component (LWC) local actions in screen flows to perform client-side operations.

For example, you can display a custom toast message after a user submits a screen, or automatically navigate them to a record page — all without making a server call. Local actions run entirely in the user’s browser, which means they are faster, more efficient, and don’t consume server resources.

Use local actions for tasks that don’t require server data (for example, UI feedback, navigation, or form resets). For operations that require Salesforce data, continue to use server-side actions.

1. What is the key benefit of using pointers to ContentDocument object IDs for large callouts?

Ans: It avoids loading large payloads onto the Apex heap, preventing heap limit errors

2. What access modifiers are supported for abstract and override methods in API version 65.0 and later?

Ans: Protected, Public, Global

3. When should you enable LWS Trusted Mode for a Lightning web component?

Ans: Only for vetted third-party scripts that require global context access

4. What advantage does the lightning/graphql module offer over lightning/uiGraphQLApi?

Ans: It supports optional fields and dynamic query construction

5. Why use LWC local actions in screen flows?

Ans: They enable browser-based actions without consuming server resources

Follow the instructions here to launch a playground (please use a new playground, not an existing one) and install the package. You also use this package and playground when it’s time to complete the hands-on challenge.

Add an Element

Add an element to trigger the record.

1. Click the Add Element icon, and select Update Triggering Record.
   
2. Update the following:
   
   • Label: Update Description
   • API Name: Update_Description
   • How to find Records to Update and Set Their Values: Use the account record that triggered the flow.
     
   • Set Filter Conditions: None - Always Update Record
     

Set Field Values for the Account Record

Next, add values to the Field column.

1. In the Field column, select Account Description.
   
2. In the Value column, click New Resource. A popup dialog box opens.
   
   • Select Text Template as Resource Type
     
   • API Name: Default_Description
     
   • In the Body section, select View as Plain Text.
     
   • Paste the following in the text editor: This is a default description.
   • Click Done.
     
3. Verify Default_Description is in the Value column.
   
4. Click Save, and set the following details:
   
   • Flow Label: Account Update
   • Flow API Name: This will autopopulate with Account_Update
   • Leave Description blank.
     
5. Click Save.
   
6. Click Activate.

Setup Test for Flow

Before testing, set up the testing parameters.

1. Click View Tests.
   
2. Click Create.
   
3. In Set Test Details, Trigger, and Path, enter the following information:
   
   • Label: Test Account Update Description
   • API Name: This will autopopulate with Account_Update_Test_Account_Update_Description
   • Leave Description blank.
     
   • Run the Test When a Record is: Created
     
4. Click the Set Initial Triggering Record tab.
   
   • In the Account Name field (you will need to scroll down to find this field), enter Account with Flow.
     
5. Click the Set Assertions tab.
   
   • In Assertion 1:
     
     • Resources: Triggering Account -> Account Description
       
     • Operator: Is Null
       
     • Value: False
       
6. Click Save.

Run and Verify the Test

You’re now ready to run and verify the tests.

1. Navigate to Setup in the top right corner of the page, and select Developer Console.
   
2. Click Debug, and select Open Execute Anonymous Window.
   
3. Paste the following command into the window: RunTestsUsingToolingAPI.runAsynchronousTestsWithToolingAPI();
4. Click Execute.
   

1. Navigate to Setup.
   
2. In the Quick Find box, search for and select Application Test Execution.
   
3. Select the Apex and flow tests you want to run, then click Run.
   
4. To check the test run results, click the View Test History link.