The delightful Salesforce Spring ’24 release is approaching, akin to the blossoming of flowers on the horizon, and the awaited release notes are here. This springtime bouquet of features brings a burst of delightful new additions!
Discover all the details to get ready for your instance’s upgrade, and find your release window here. But for now, let’s dive into the heart of this blooming landscape and explore the most captivating features and updates – crafted specifically for developers – in the Salesforce Spring ‘24 release.
1. Updated Migrate to Flow Tool for Migration of More Processes
The Migrate to Flow tool has undergone an update to support partial migration for most actions, excluding invocable actions. This enhancement provides users with the flexibility to partially migrate all actions within the tool. The migration results generated by the tool specifically highlight which actions require additional configuration in Flow Builder to ensure a comprehensive and successful migration.
To utilize this improved functionality, users can access the Migrate to Flow tool from Setup by entering “Migrate to Flow” in the Quick Find box and selecting the corresponding option. Subsequently, users can choose the specific process they wish to convert into a flow and initiate the migration process. During migration, the tool allows users to select criteria for migration, with a clear indication in the Migrateable column regarding the partial migratability of each process.
Upon completion of the migration, users can efficiently review the results by clicking on “Needs Review”, where a list of actions requiring additional configuration in Flow Builder is presented. This streamlined approach enhances the overall migration experience, making it more adaptable and transparent for users transitioning from processes to flows.
2. New Aura Components with Better Functionality
There has been a change to the lightning:navigation, which has undergone some modifications to enhance its functionality.
The key adjustment centers around the replace property within the navigate(pageReference, replace) method, specifically concerning quick action navigation, such as creating a new record. When replace is set to false (the default), saving a new record through a pop-up modal returns the user to the previous record page.
For instance, creating a new contact via a Quick Action on an account page brings the user back to that account page after saving. Conversely, if replace is set to true, the post-saving navigation differs. After saving a new record in a pop-up modal, the user is instantly redirected to the page of the newly created record. This adjustment in the lightning:navigation component provides increased flexibility in determining the user’s destination after specific actions, particularly in scenarios involving the addition of new records.
Here’s an example using the lightning:navigation component and the replace property:
// Example 1: replace set to false (default)
var pageReference = {
type: 'standard__recordPage',
attributes: {
objectApiName: 'Contact',
actionName: 'new'
}
};
// Navigate with replace set to false
component.find("navigationService").navigate(pageReference, false);
// After saving a new contact through a pop-up modal, the user is returned to the previous record page.
// For instance, if a new contact is created via a quick action on an account page, the user goes back to the account page after saving.
// Example 2: replace set to true
var pageReference = {
type: 'standard__recordPage',
attributes: {
objectApiName: 'Contact',
actionName: 'new'
}
};
// Navigate with replace set to true
component.find("navigationService").navigate(pageReference, true);
// Post-saving, the navigation behavior is different. After saving a new contact in a pop-up modal,
// the user is redirected to the page of the newly created contact.
// For example, adding a new contact from an account page would direct the user to the newly created contact's page right after saving.As you can see above, the first navigation scenario uses the default setting with replace set to false, and the second scenario explicitly sets replace to true. These scenarios demonstrate the different navigation behaviors after saving a new contact, depending on the value of the replace property.
3. Lightning Web Components Enhancements
Several changes have been made to Lightning Web Components, affecting specific components and introducing new attributes and behaviors. The lightning-datatable component now includes a new attribute called wrap-table-header, allowing the header text to wrap within column widths. Additionally, it supports a custom data source component for dynamic determination of custom data types at runtime.
Example for lightning-datatable changes:
<!-- New attribute: wrap-table-header -->
<lightning-datatable
key-field="id"
data={data}
columns={columns}
wrap-table-header={true}>
</lightning-datatable>As you can see, the wrap-table-header attribute is set to true, allowing the header text to wrap within column widths.
The lightning-input component introduces a new attribute called role, enabling the creation of accessible combo boxes. Accessibility behaviors have been added or modified, including passing down ARIA attributes for various input types and removing the role=alert attribute for specific input types.
Example for lightning-input changes:
<!-- New attribute: role -->
<lightning-input
type="text"
role="combobox">
</lightning-input>With the new rules, the focus will be on the title text when a header is present. If there is no header, it will focus on the first interactive element in the body, and if there is none, it will focus on the close button.
Changes in accessibility behaviors are noted for the lightning-pill and lightning-pill-container components, specifically regarding keyboard navigation and the activation of remove buttons. The lightning-record-form and lightning-record-picker components introduce new behaviors related to multiple currencies and field-level help.
Example for lightning-record-picker changes:
<!-- New attributes: field-level-help and disabled -->
<lightning-record-picker
field-level-help="Select a record"
disabled>
</lightning-record-picker>The field-level-help attribute provides help text, and the disabled attribute disables the component.
The lightning-tabset component sees the addition of new attributes like heading-label, heading-level, and heading-visible for customized assistive text and visibility control. Accessibility behaviors have been modified to allow keyboard navigation to the ‘more’ menu using tab and arrow keys. These changes aim to enhance the flexibility and accessibility of Lightning Web Components in building user interfaces.
Example for lightning-tabset changes:
<!-- New attributes: heading-label, heading-level, heading-visible -->
<lightning-tabset
heading-label="Custom Tabs"
heading-level="3"
heading-visible={true}>
<!-- Tab components go here -->
</lightning-tabset>These new attributes allow customization of assistive text for tabset headings, set the heading level, and control visibility of the heading text above the tabset.
4. New and Changed Apex Items
There are several new or changed Apex items in the Spring ‘24 release…
Auth Namespace
New classes, methods, interfaces, enums, and exceptions for OAuth token validation and management. Notable additions include handling JWTs, token validation results, and OAuth token revocation.
Example: OAuth token validation
// Validate incoming token
Auth.Oauth2TokenExchangeHandler.validateIncomingToken('myApp', Auth.IntegratingAppType.Web, 'xyzToken', Auth.OAuth2TokenExchangeType.AccessToken);IsvPartners Namespace
Introduces a new namespace for AppExchange App Analytics with methods like logCustomInteraction.
Example: Logging custom interaction for App Analytics
// Log a custom interaction
IsvPartners.AppAnalytics.logCustomInteraction('UserClickedButton');ConnectApi Namespace
Houses new or changed classes, methods, and enums for Connect REST API actions in Apex.
Example: Calling Connect REST API in Apex
// Example method call for Connect REST API
ConnectApi.ChatterFeeds.getFeedItemsFromFeed('me', ConnectApi.FeedType.News);System Namespace
Adds new classes, methods, interfaces, enums, and exceptions. Highlights include UUID generation, improved DML validation, explicit savepoint release, setup page hostname retrieval, and enhanced quiddity identification.
Example: UUID generation
// Generate a UUID
String uniqueId = System.UUID.randomUUID();Compression Namespace (Developer Preview)
Used for generating and extracting compressed files. Includes classes for zip operations with features like compression level specification.
Example: Improved DML validation
// Compress zip entries and get the compressed content
Blob compressedData = Compression.ZipWriter.getArchive('file1.txt', 'file2.txt');FormulaEval Namespace (Developer Preview)
Evaluates dynamic formulas in Apex with classes for building, validating, and executing formulas. Introduces methods and enums for specifying formula details and return types.
Example: Building and evaluating a formula
// Build a formula
FormulaBuilder formulaBuilder = new FormulaBuilder().withFormula('A + B').withReturnType(FormulaReturnType.Number);
// Evaluate the formula
FormulaInstance formulaInstance = formulaBuilder.build();
Decimal result = formulaInstance.evaluate();These updates offer expanded functionality and improved capabilities across various namespaces in Salesforce Apex.
5. ICU Locale Formats for Global Compatibility
In Spring ‘24, there’s a new update that lets you use International Components for Unicode (ICU) locale formats for dates, times, numbers, and currencies in Salesforce.
Think of it like this: You’re making apps in Salesforce, and you want them to show dates, times, numbers, and money in a way that suits users from different places. Turning on the ICU locale formats feature is like having a magic wand that uses the powerful ICU library to format things like dates and numbers based on what users like in their area. This ensures your apps give a smooth and culturally fitting experience for users all around the world.
This feature makes your apps even better by making sure dates, times, numbers, and currencies look right for each user’s culture and region. It lets your apps smoothly switch between different languages and places for a consistent user experience.
With ICU locale formats, you get many choices for how things are formatted, making sure your app looks sharp and accurate. Plus, it makes your life easier by simplifying the formatting part, letting you focus more on building the important features of your app. It’s like having a helpful assistant to make your app look good and work well.
6. More Secure Visualforce JavaScript Remoting API with JsonAccess Annotation Validation
In the Spring ‘24 release, there’s an update that boosts the security of the Visualforce JavaScript Remoting API. It does this by checking the JsonAccess annotation in your Apex classes, making sure no one unauthorized can mess with your data by moving it around in different packaging namespaces.
Imagine you’re building a Visualforce app that connects with your Apex classes using the Visualforce JavaScript Remoting API. You just want your Apex classes to be super safe, right? Well, turning on the JsonAccess Annotation Validation feature acts like a security guard, making sure your data stays put and isn’t moved around without permission. This is like locking the door to keep your data safe and sound, away from anyone trying to snoop around.
This security feature not only protects your Apex classes from unauthorized access but also prevents sneaky attempts to mess with your data by stopping it from being moved between different areas. It’s like having a bodyguard for your data, making sure it stays intact and secure.
7. Data Cloud-Triggered Flows With New Debug Tools
The new Data Cloud-Triggered flow debug tool in Flow Builder serves a dual purpose by facilitating the testing of flow behavior and aiding in the troubleshooting of potential issues. Users can now simulate the execution of their flows without impacting real data, ensuring that the flow performs as expected before deployment or making modifications.
To utilize this feature, users should navigate to Flow Builder and select the Data Cloud-Triggered flow they wish to assess. Upon choosing the desired flow, they can access the “Debug” option within Flow Builder. In debug mode, users can select a specific Data Cloud record to test the flow against. This record serves as a trigger to assess how the flow responds under different conditions.
Once the Data Cloud record is selected, users can run the debugger to observe the flow’s execution with that specific record. This step-by-step walkthrough of the flow’s behavior helps in identifying and understanding any issues that may arise during its execution.
The applicability of the Data Cloud-Triggered flow debug tool extends across both Lightning Experience and Salesforce Classic, making it accessible to users across all editions of Salesforce. This tool is particularly valuable for its risk-free testing environment, allowing users to validate flow behavior without unintended consequences on actual records.
Additionally, it streamlines the troubleshooting process by providing an efficient way to isolate and address issues within the flow logic. In essence, this feature enhances the overall testing and troubleshooting capabilities for Data Cloud-Triggered flows in Salesforce.
8. Beta Feature: Scratch Org Snapshots for Efficient Configuration in Salesforce
Salesforce has introduced a Beta feature called “Scratch Org Snapshots” that allows users to capture a point-in-time copy of a scratch org’s configuration. This snapshot can then be used to create replicas of scratch orgs, providing a streamlined approach for replicating specific configurations. It’s essential to note that this feature is in Beta, and customers can choose to try it at their discretion, with usage subject to applicable Beta Services Terms.
The availability of Scratch Org Snapshots spans both Lightning Experience and Salesforce Classic and applies to Developer, Enterprise, Performance, and Unlimited editions. This feature becomes accessible when the Dev Hub org is upgraded to the Spring ’24 release.
The significance of this feature lies in simplifying the typically manual and time-consuming process of configuring scratch orgs with project dependencies. Users can enable Scratch Org Snapshots in their Dev Hub org, and Salesforce CLI commands, like org create snapshot and org list snapshot, can be employed to manage and create snapshots. In essence, Scratch Org Snapshots enhance efficiency by enabling quick replication of scratch orgs with specific project dependencies, minimizing the need for repetitive manual configurations.
9. Apex REST API Enhancement: Enforcing RFC 7230 Validation
In the Spring ‘24 release, there’s a new improvement to make your Apex REST API responses work better. It follows a set of rules called “RFC 7230” to ensure your API responses are named and structured correctly.
Think of it like this: when you’re building an Apex REST API for your Salesforce data, you want it to play nice with other apps, right? Enabling the RFC 7230 header check for your API responses is like a traffic cop, ensuring everything follows the rules.
This brings a bunch of advantages, like making your responses consistent, easy to understand, and ready to team up seamlessly with other RESTful apps. It’s like giving your API a smooth highway for communication, reducing errors, and making sure everything flows smoothly between your app and others.
The following is an example to illustrate this new improvement:
@RestResource(urlMapping='/exampleEndpoint/*')
global with sharing class ExampleRestController {
@HttpGet
global static String doGet() {
// Assume you're retrieving some Salesforce data
String responseData = '{"accountId": "001XXXXXXXXXXXXXXX", "name": "Sample Account"}';
// Set the RFC 7230 header to enable the check for structured and named responses
RestContext.response.addHeader('RFC-7230-Check', 'enabled');
return responseData;
}
}In this example, an Apex REST endpoint is created (/exampleEndpoint/) using the @RestResource annotation. The doGet method is handling the HTTP GET request. The response data is a JSON representation of a sample Salesforce account.
The key addition is the use of RestContext.response.addHeader('RFC-7230-Check', 'enabled');. This line adds the RFC 7230 header to the API response, signaling that the response follows the specified rules for naming and structuring.
By incorporating this header, your Apex REST API responses will align with RFC 7230, ensuring consistency, clarity, and seamless integration with other RESTful applications. It’s like having a traffic cop to ensure your API communication flows smoothly and error-free between your Salesforce app and others.
10. Apex REST API Defaults to JSON for HTTP ACCEPT Headers
The changes in the Apex REST API mean that when you access Apex classes, the API now acts like other Salesforce APIs. If the HTTP ACCEPT header is missing or messed up, the Apex REST API will simply default to returning data in JSON format. This makes things simpler when dealing with headers.
Just remember, the valid values for the HTTP ACCEPT headers are application/json or application/xml, and they are case-sensitive. In the past (API version 59.0 and earlier), if the ACCEPT header was missing or not right, the Apex REST API would give an error for content types like application/Xml. Now, it falls in line with other Salesforce REST APIs by defaulting to a JSON response when it encounters a missing or messed-up HTTP ACCEPT content type. This change brings consistency across Salesforce APIs and makes handling content types in HTTP headers more straightforward.
The “BEHAVIOR CHANGE: Apex REST API HTTP ACCEPT headers now default to JSON” means that when using the Apex REST API, if you don’t specify the Accept header or if it is malformed, the API will now default to returning data in JSON format. This aligns the behavior with other Salesforce APIs.
Here’s an example of how this change impacts your usage of the Apex REST API…
Before this change (prior to API version 60.0):
// Request without specifying Accept header
GET /services/apexrest/yourEndpointResponse (example):
<error>Unsupported Content-Type</error>Now, with the change (API version 60.0 and later):
// Request without specifying Accept header
GET /services/apexrest/yourEndpointResponse (example):
{"error":"Unsupported Content-Type"The example demonstrates that if you make a request to your Apex REST API without specifying the Accept header or if it is malformed, the API will return a JSON response by default. Before API version 60.0, it would have returned an error in XML format. Please note that valid values for the Accept header are application/json or application/xml, and they are case-sensitive. This change simplifies the behavior and aligns it with the default behavior of other Salesforce REST APIs.
Summary
And there you have it – our overview of the most vibrant Salesforce Spring ’24 release features, tailored especially for developers.
Have you come across any other fresh new additions? Share your discoveries in the comments!
Read More
- Spring ’24 Release Highlights for Account Engagement (Pardot)
- Salesforce Spring ’24 Features: Top 10 Admin Updates You Need to Know
- Salesforce Spring ’24 Features: Top 10 Flow Updates You Need to Know
Comments: