It’s been a bit since I’ve had a new post. I have been busy creating courses for Salesforce Ben such as the Introduction to Salesforce Apex course. The “Introduction to SOQL” course is in review and work has begun on the “Apex Triggers” course.
Now, let’s get down to business with the Spring 23 release with the release notes.
Bulk Manage Picklist Values
Save time managing your picklists. You can now delete, activate, deactivate, or replace multiple custom picklist field values at once. Previously, you modified them one at a time. This feature is available only for custom picklists with predefined values. This feature is generally available.
This is a nice time saving feature when having to manage your picklists, especially when building out a new data model!
Enhance Case and Lead Record Pages with Dynamic Forms
Make your case and lead record pages more robust by configuring them with Dynamic Forms. Previously, this capability was available only for account, person account, contact, and opportunity record pages.
This one makes me a little giddy. I’ve been wanting this for Cases, like everyone else, ever since Dynamic Forms were released! I especially want to see if the custom action buttons now work the same as everywhere else or not!
See More Records in Dynamic Related Lists
With the Dynamic Related List – Single component, admins define and filter related lists directly from the Lightning App Builder. Like other related lists, dynamic related lists now include a View All link so that users can see a full list of related records. In the full related list, users can also add quick filters and see the filters that their admin applied. Previously, users saw only up to 30 records in a dynamic related list on the record detail page.
Sometimes one has to defer full functionality until later to get a feature out that’s useful. Am happy to see that there’s a “View All” link so users can see the full list of related records on Dynamic Related Lists!
Enhance Your Dynamic Form Related Pages With Custom Address Fields
Improve address data accuracy and your users’ experience with custom address fields, now supported in Dynamic Forms. When you create a custom address field on a Dynamic Forms-enabled object, that field is now available in the Fields tab when you edit record pages for that object in Lightning App Builder.
Custom addresses are now available in Dynamic Form record pages! They have limitations but offer a much needed option for custom objects.
Learn Who Can Access Records & Why
Understanding who can access a record is critical to securing record access in your organization. Check out a record’s sharing hierarchy to view who it’s shared with. You can also see the user’s reason for access and find out if a user’s access is blocked by a restriction rule.
Where: This change applies to Lightning Experience in Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: To see a list of users who have access, click Sharing Hierarchy from the Action Menu on the desired record. To see why the user has access to the record or why access is blocked, click View next to the user’s name. When you click View, all applicable sharing reasons appear, including the names of owner-based and criteria-based sharing rules.If a restriction rule blocks access to the record, a message appears to confirm that access is blocked.
I’m glad one no longer has to go back to Classic to see this information and it’s available in Lightning now!
Query DOM Elements with Ref
Now you can use refs to access elements in shadow DOM and light DOM. Refs locate DOM elements without a selector and only query elements contained in a specified template. Previously, you could only use querySelector() to locate specific DOM elements.
Where: This change applies to Lightning Experience, Salesforce Classic, and all versions of the mobile app in all editions.
How: First, add the lwc:ref directive to your element and assign it a value. To call that reference, use this.refs. In this example, the <div>element has the directive lwc:ref=”myDiv”, which this.refs references to access the <div> at runtime.
If you call this.refs for a nonexistent ref, it returns undefined. If the template contains duplicate lwc:ref directives, this.refs references the last directive. For a component with more than one template, this.refs refers to the most recently rendered template.
<template>
<div lwc:ref="myDiv"></div>
</template>
export default class extends LightningElement {
renderedCallback() {
console.log(this.refs.myDiv);
}
}
This is a provides an easier way to reference DOM elements without having to use DOM selectors! One should try to use this for new LWCs over the querySelector function whenever possible because there’s less code and the intent is clearer!
Use Improved Conditional Directives
The lwc:if, lwc:elseif, and lwc:else conditional directives supersede the legacy if:true and if:else directives.
Where: This change applies to custom Lightning web components in Lightning Experience, Experience Builder sites, and all versions of the Salesforce mobile app. This change also applies to Lightning web components in Open Source.
How: With the lwc:if, lwc:elseif, and lwc:else conditional directives, the property getters are accessed only one time per instance of the directive.
<!-- conditionalExample.html -->
<template>
<template lwc:if={isTemplateOne}>
This is template one.
</template>
<template lwc:elseif={expression2}>
This is template two
</template>
<template lwc:else>
This is template three.
</template>A developer should now only use these new lwc:if, lwc:elseif, and lwc:else directive instead of the if:true or if:else directives because they only cause the Javascript getters to fire once instead of multiple times so the performance will be better!
Synchronize Component Data without a Page Refresh using RefreshView API (Beta)
Whether user-driven or app-invoked, the ability to synchronize data without reloading an entire page is a key user experience requirement. The new lightning/refresh module and RefreshView API provide a standard way to refresh component data in LWC and Aura. Previously, LWC lacked a data refresh API, and Aura only supported the legacy force:refreshView, which doesn’t meet the requirements of modern web development. RefreshView API’s detailed control of refresh scope lets developers create refined user experiences while maintaining backward compatibility.
Where: This change applies to Lightning Experience in Enterprise, Unlimited, and Developer editions.How: RefreshView API updates the data for a specific hierarchy of components, known as a view, without reloading an entire page. This refresh ensures complete synchronization with data externally sourced by components that subscribe to the refresh event in that view. RefreshView API synchronizes data externally sourced by components in that view and supports refreshes triggered by end users or web components. RefreshView API provides a standard mechanism for data refresh experiences in both LWC and Aura components. It allows flexible control of refresh scopes, and for Aura developers it can replace the legacy force:refreshView. RefreshView API can refresh data for Salesforce platform containers as well as custom components.
LWCs are my first choice when creating new Lightning components but recently I had to create an Aura component because it needed to refresh the standard components on the record page and the force:refreshView event is 1 line of code versus the current LWC workarounds that exist to make this happen. When this becomes GA, it’s one less reason to create new Aura components!
Dynamically Pass Bind Variables to a SOQL Query
With the new Database.queryWithBinds, Database.getQueryLocatorWithBinds, and
Database.countQueryWithBinds methods, the bind variables in the query are resolved from a Map parameter directly with a key rather than from Apex code variables.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.How: In this example, the SOQL query uses a bind variable for an Account name. Its value (Acme Inc.) is passed in to the method using the nameBind Map. The accountName variable isn’t (and doesn’t have to be) in scope when the query is executed within the method.
public static List<Account> simpleBindingSoqlQuery(Map<String, Object> bindParams) {
String queryString =
'SELECT Id, Name ' +
'FROM Account ' +
'WHER name = :name';
return Database.queryWithBinds(
queryString,
bindParams,
AccessLevel.USER_MODE
);
}
String accountName = 'Acme Inc.';
Map<String, Object> nameBind = new Map<String, Object>{'name' => accountName};
List<Account> accounts = simpleBindingSoqlQuery(nameBind);
System.debug(accounts);This is a nice new feature addition for dynamic SOQL where the data bind variable does not have to be in scope. This allows one to build more dynamic “Selector” classes if one desires.
Manage and Release Changes with DevOps Center (GA)
Manage your changes and releases using the DevOps Center point-and-click interface, or directly from the source control system, or a combination of both. Under the hood, we manage the source control branches so developers and builders can focus on development tasks.
This is a potential game changer for native Salesforce deployments! I say potential because further evaluation is needed to assess if this can be recommended immediately or under what circumstances this can replace what a team is using for their release and deployment process. For example, it requires a GitHub account, which not all companies may allow. It’s also nice that’s it’s free and included in one’s Salesforce subscription.
Quickly Clone Full & Partial Sandboxes
For Partial and Full sandboxes hosted on Hyperforce, the Quick Clone technology enhances the speed at which they’re replicated. Teams can focus more time on building and testing solutions, and less time waiting for sandboxes to be cloned.
It’s nice this is available for Hyperforce but I wish it was available for non-Hyperforce customers too! It would be nice if Salesforce could transfer existing customers to other public clouds automatically without disruption to provide better scalability but alas that seems like too much to ask.
Get the Play-By-Play with Field History Tracking for Activities
See a list of changes to events and tasks when you turn on field history tracking. Track up to six fields so that sales reps can see what’s changed in the Related tab for events and tasks.
Where: This change applies to Lightning Experience in all editions.
How: Pick which fields to track in the Object Manager. From Setup, go to the Object Manager and select the Event or Task object. Select Fields & Relationships, then click Set History Tracking.
I totally forgot that Field History Tracking was not availabe on Tasks and Events! Now one can track up to 6 fields on them using the usual “Set History Tracking” button.
Build Screens with Reactive Components (Beta)
Configure supported components or your custom Lightning Web Components to react to changes in other components on the same screen. Previously, components on the same screen couldn’t talk to each other, so if you needed one component to influence another, you placed them on separate screens. Now you can build screens that feel like single-page applications and reduce the number of
screens for your user. Reactivity is supported with API version 57.0 or later.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Unlimited, and Developer editions.
This greatly enhances the UI one can build in a flow screen. For example, as one input changes, other things on the screen can change too. This previously was only possible with LWCs but now that it’s native to flows, this greatly enriches the user experience and allows even greater possibilities. However, it’s still in Beta so wait until it’s GA for production use.