Ravindra Yadav, Senior Product Manager at Provar, contributed this post. Follow our blog for more insights from our Salesforce and testing experts!

Salesforce’s Spring ’24 release is here, bringing forth a bunch of cool features and innovations. Like everywhere else, Artificial Intelligence is taking center stage. From advanced Einstein capabilities to data cloud enhancements and the introduction of AI into various core parts of the release, this release promises a world of possibilities.

But, as Provar’s Senior Product Manager and a testing enthusiast, my primary focus is on highlighting the key elements of Spring ’24 that hold special significance for testers. Let’s dive into the features that not only add value but also enhance efficiency in the testing world.

ICU Locale Formats Enablement

International Components for Unicode (ICU) enablement stands out as a significant change in the Spring ’24 release. This change of ICU locale formats impacts the formatting of dates, times, currencies, addresses, names, and numeric values. Once you activate this update, Salesforce transitions from Oracle’s Java Development Kit (JDK) locale formats to the ICU locale formats. Initially introduced in Winter ’20, the enforcement of this update is currently underway and will be systematically rolled out starting in Spring ’24.

Additionally, users have the flexibility to defer enforcement until Spring ’25 through the user interface.

Possible Impact on Testing

Given that the ICU locale format change directly influences the presentation of dates, times, currencies, addresses, names, and numeric values, testing teams must take proactive steps to align their test scenarios with these changes. Testers should update their expected value formats in test scripts for assertions to reflect the changes in the appearance of these elements. Additionally, any variables or functions used to generate these values may need updates.

Overall areas impacted by this alteration include data validations, integration testing, Localization/Globalization tests, and regression testing.

Below is an example of a Date Time Field for the English India locale:

  • Before ICU: 31/10/2019 18:00
  • After ICU: 31/10/2019, 18:00

Provar users can view this help page for guidance.

Add Fields from Related Objects on Dynamic Forms

In the Spring ’24 release, Salesforce introduces a community demanded enhancement, enabling a dynamic form page to display fields from related objects. This enhancement aims to reduce the complexity for admins and developers by eliminating the need for intricate cross-object formulas. Starting with the Spring ’24 release, users can seamlessly reference fields from related objects directly in dynamic forms.

Possible Impact on Testing

Given that this feature is a recent addition, any updates from admin involving the removal of formula fields or the addition of related object fields must be addressed. This includes handling any new cross-object fields or adjusting the approach to existing formula fields from related objects on the dynamic form screen for both manual and automation test scripts.

Set Field Visibility by Device in Dynamic Forms

Visibility rules are an important feature of Dynamic Forms. However, customization of visibility rules based on the device form factor was limited to Field Sections and components in the past. Now with the Spring ‘24 release, you can achieve more granular customization of Lightning record pages for desktop and mobile experiences. This enhancement allows admins to restrict field visibility as well based on the device form factor, whether it’s on a desktop or phone view.

Possible Impact on Testing

The introduction of additional visibility criteria for fields has a direct impact on the visibility of these fields on the screen. Consequently, when testing dynamic form screens, it becomes essential to consider the device on which the page is being viewed. Tests should incorporate conditional checks, both in manual testing and automation scripts, to accommodate variations between desktop and mobile device executions.

Provar Automation users can leverage visibility criteria within Provar’s Test Builder while authoring tests. This enables them to seamlessly update and incorporate these additional conditions in test cases without the need to navigate to the setup of the dynamic form page. This streamlined process ensures efficient and comprehensive testing, providing flexibility for users to adapt their test scripts to varying device contexts.

Einstein Search is Enabled by Default

Einstein Search has been a feature for some time, but its accessibility was previously limited to the orgs with MySearchPilot and SearchAssistant permissions. In the Spring ’24 release, Einstein Search is now universally available and activated by default in all Salesforce orgs, unless the DoNotAutoEnable flag is turned on. This intelligent and powerful search tool enhances user experience, enabling quicker task completion, direct actions from search results, and the delivery of more relevant and personalized information.

AI Aspect

With the latest GA release, Einstein Search now offers AI-generated search answers, crafting responses to your queries based on knowledge articles and various sources. Pilot customers using Search Answers must ensure they have the required SKUs and re-enable the feature to activate AI-generated search responses.

Possible Impact on Testing

Since the layout of the Global search will completely change to this interacting Einstein Search bar, testers may have to recreate their test scripts to adapt to these UI changes in both manual as well as automated test scripts. Additionally, the suggestion box will have data coming from Einstein intelligence that needs to be handled accordingly in the data strategy. This also impacts the search result layout, which needs to be updated.

Provar allows users to use the same global search scripts for the Einstein search as well, and scripts for new elements of Einstein search can be authored easily as Provar already provides support for Einstein search.

Changes in the Lightning Web Component

Salesforce is gearing up to incorporate native shadow DOM in the foundational Lightning components to improve performance and align with Web Components standards. These adjustments include changes to the internal DOM structures, including the lightning-input component.

With the Spring ’24 release, these additional components have been modified to prepare for the implementation of native shadow DOM.

  • lightning-alert
  • lightning-badge
  • lightning-button-group
  • lightning-confirm
  • lightning-formatted-address
  • lightning-formatted-date-time
  • lightning-formatted-email
  • lightning-formatted-location
  • lightning-formatted-phone
  • lightning-formatted-rich-text
  • lightning-formatted-text
  • lightning-formatted-time
  • lightning-formatted-url
  • lightning-input-address
  • lightning-input-name
  • lightning-input-location
  • lightning-input-rich-text
  • lightning-layout
  • lightning-layout-item
  • lightning-menu-subheader
  • lightning-modal
  • lightning-modal-body
  • lightning-modal-footer
  • lightning-modal-header
  • lightning-prompt
  • lightning-rich-text-toolbar-button
  • lightning-rich-text-toolbar-button-group
  • lightning-toast
  • Lightning-toast-container

Possible Impact on Testing

These DOM changes, specifically the adoption of native shadow DOM in foundational Lightning components, will significantly impact coded test automation tools. Test scripts will need to be recreated to adapt to these changed shadow DOM renderings. It is important to verify that the selected automation tool can seamlessly handle the shadow DOMs. Additionally, comprehensive cross-browser testing is recommended to ensure the effectiveness of these shadow DOM change handling across different browsers.

Provar addresses these shadow DOM changes adeptly, accommodating both standard and custom LWC components. Leveraging its updated libraries, Provar Automation offers robust scripts that operate effectively without incurring maintenance overhead. This ensures a smooth transition in the face of evolving DOM structures, highlighting Provar’s proficiency in handling these evolving DOM structures effortlessly.

LWC Rendering on More Record Home Pages

In the Spring ’24 release, an expanded range of objects are now Lightning Web Components (LWC) enabled, enhancing user experiences when creating, viewing, or editing record home pages. This change brings notable improvements in performance, increased accessibility support, and enhanced service availability. As part of Salesforce’s broader commitment to integrating LWC, the majority of record home pages now use LWC rendering. 

See full list here.

Possible Impact on Testing

Similar to the previous section, the introduction of LWC rendering has significant implications for automation tests. This change has the potential to disrupt automation scripts created with previous DOM elements. To make sure everything runs smoothly, we need to go through all the locators in our automation scripts and update them. This is important to keep our automation tests working well with the new LWC rendering.

New Home Screen for Sellers

The sales application introduces a revamped Home Screen featuring an enhanced view and components. Users can now access an overview of their opportunities, accounts, leads, and contacts, alongside a display of their day’s agenda. Additionally, the Home Screen includes useful elements such as to-do list, recent records and contact suggestions generated by Einstein. Seller Home is the default Home page for the Sales, Sales Console, and Sales Engagement apps.

Possible Impact on Testing

The updated seller home screen will be visible by default if a custom home page hasn’t been applied to the relevant apps. Even if you’ve customized these home pages, you can still enable the new seller home from Home items in Setup. It’s essential to note that this UI and component list modification differs from the previous home screen. Therefore, any existing manual and automation tests must be recreated to align with this change on the new seller’s home screen.

Salesforce Scale Center

Salesforce Scale Center is a self-service tool designed to provide a comprehensive overview of your org’s performance and help enhance scalability. It allows for a deep dive into these hotspots for root cause analysis and remediation guidance. As your company introduces new changes and your implementation grows in complexity, adhering to best practices and vigilantly monitoring the performance impact of these enhancements becomes essential.

To learn more, read Salesforce’s announcement blog.

Scale Test is also available as a paid add-on for customers with a Full Copy Sandbox, which includes the Test Scheduler and Test Execution features

Possible Impact on Testing

This represents another non-functional aspect of testing that can be integrated with functional tests to monitor org performance. Incorporating this aspect enhances your debugging capabilities, allowing you to isolate root causes and identify potential problem areas. Once identified, these issues can be addressed, contributing to the scalability of your application. 

For an in-depth exploration of Scale Center from a tester’s perspective, read our blog post.

Intelligence View for Leads, Contact, and Account 

Salesforce has introduced Intelligent views for Leads, Contact, and Account objects, making it easier to access key information in one place for better efficiency. The Lead Intelligence View helps identify engaging leads that may need more attention. For accounts, the Account Intelligence View provides a consolidated overview of account activity, opportunity metrics, case reviews, and activity logging. Similarly, the Contact Intelligence View offers insights into cases, emails, and Einstein Conversations for improved engagement.

These features can be easily accessed from the Home list view screen by clicking on the Intelligence View button.

Possible Impact on Testing

Since these intelligence views are new screens, it may require testers to create new test cases for both manual and automated testing to ensure thorough coverage. Existing List View tests are anticipated to function without any issues. However, it’s important to be cautious about the default view — if using List View tests, ensuring that the default view is not changed to Intelligence View or Including List View click actions in the test steps is advisable to prevent unexpected failures in test scripts.

Permission Set Groups in All Editions

With the Spring ’24 release, Permission Set Groups are now available in all editions, expanding their accessibility. Permission sets, which were previously limited to selected editions, can now be used across the board. Permission Set Groups serve as an effective mechanism for managing org permissions and assignments, allowing the consolidation of modular permission sets together based on user job personas or roles.

Possible Impact on Testing

While the introduction of Permission Set Groups may not directly impact testing, it streamlines the testing of permissions-specific functionalities. Permission set groups provide an efficient way to create distinct permission set groups, simplifying the validation process for scenarios related to access and permissions of fields, objects, layouts, and more. This enhancement enhances the overall testing process by offering a more organized and systematic approach to managing permissions.

Unannounced Changes

The release notes mention several changes, but it’s important to keep an eye on things not explicitly stated that could have a big impact, especially for automated testing. Here are a few examples to consider.

Related Record Framework Change

The Related Record component has undergone a significant framework change from Aura to LWC, resulting in comprehensive changes to the DOM rendering of these components on the page.

Changes Related to List View and View All

The table view of the related list has observed a component change in the LWC and the addition of a new class attribute has replaced the older class.

New and Edit Screens

The DOM changes on new and edit screens are similar to the DOM changes on inline edit screens, where the structure of labels and field values in the DOM is updated for read-only fields.

See Provar’s release notes for the complete list and details of changes.

Other Useful Features 

Please don’t hesitate to contact us if you have any questions or if you’d like to delve into any of the topics above further!

Interested in learning how our solutions, including Provar Automation, can help enhance your Salesforce strategy? Schedule a demo today!