Since I just published the Salesforce Spring Release review and I have some time while traveling, I thought I’d review the Summer 23 Release Notes and provide my review here. The release notes were published this week and are hot off the press!
There were many small platform improvements in this release that’ll help admins and developers. Some notable items are
- Automate and Migrate User Access with User Access Policies
- Mass Quick Actions on Related Lists
- Synchronize Component Data Without a Page Refresh Using RefreshView API
- Query Five Levels of Parent-to-Child Relationships in SOQL Queries
- Update Flow Screens In Real-Time using Formulas
- Use Email Templates in the Flow Send Email Action
Experience Improved performance on More Record Home Pages
With Lightning Web Components (LWC)-enabled objects, you can create, view, or edit the record home pages with improved performance, stronger accessibility support, and better service availability. Over 100 more objects now use LWC to render record home pages, bringing the total objects to over 1,000.
Where: This change applies to Lightning Experience and all Salesforce mobile apps in all editions.
Why: As part of LWC enablement at Salesforce, approximately 80% of all record home pages now render using LWC.
It’s helpful that even more of the Lightning UI is powered by LWCs to provide even better performance! Personally, I still find Classic faster for many things but it’s great that Lightning will be faster.
Get Better Performance for Related Lists
The related list View All page now renders using Lightning Web Components (LWC) instead of Aura, improving user experience and providing stronger accessibility support. Using LWC, the full list of related records loads earlier and renders faster.
Where: This change applies to Lightning Experience in all editions.
How: The related list View All page renders using LWC only for objects that are LWC-enabled. The LWC-enabled View All page includes these minor visual changes, but the way that your users work in related lists hasn’t changed.
News, Automated Account Fields, and Accounts Logos are Being Retired
The News, automated account fields, and automated account logo features are being retired in all Salesforce orgs in Winter ’24 on October 13, 2023. After these account features are retired, Salesforce doesn’t prompt users with suggestions for account names and doesn’t fill out fields or add company logos automatically. The News component is removed from page layouts.
Where: This change applies to Lightning Experience in Essentials, Group, Professional, Enterprise, Performance, and Unlimited editions
This is a big bummer. It was nice to see a company’s news and their logo on the account record! I wonder why this is being done? Perhaps it is too much too support?
Set Field-Level Security for a Field on Permission Sets Instead of Profiles (Generally Available)
When you create a field, set its field-level security on permission sets instead of profiles. Or, modify the field-level security for an existing field for all permission sets in Object Manager. This change makes it easier to follow the user access control best practice of using permission sets to manage your users’ permissions rather than profiles. This feature, now generally available, includes an enhancement
so that you can see each permission set’s object permissions for the field’s object without leaving the page.Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
How: From Setup, in the Quick Find box, enter User Management Settings, and then select User Management Settings. Enable Field-Level Security for Permission Sets During Field Creation. Now, when you create a field, set field-level security on an existing field, or change a custom field’s type, you assign field-level security for permission sets instead of profiles.
This is very nice. With the push to use permission sets for Field-Level Security, it makes sense to let one specify the permission sets to grant access to when creating and updating an Object’s field.
Automate and Migrate User Access with User Access Policies (Beta)
Automate your users’ assignments to managed package licenses, permission sets, and other access mechanisms based on criteria that you set. Create user access policies that automatically grant or remove access whenever users are created or updated. Or, easily migrate large sets of users to a new access setup in a single operation. Previously, Salesforce enabled user access policies, but you can now enable this beta feature on the User Management Settings Setup page. Also since the last release, you can now set more complex user criteria and monitor recent user access changes.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise and Unlimited editions.
Note: This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.
How: From Setup, in the Quick Find box, enter User Management Settings, and then select User Management Settings. Enable User Access Policies (Beta). Then, in the Quick Find box, enter User Access Policies, and then select User Access Policies to create or manage your user access policies.
If Salesforce enabled user access policies for you before the Summer ’23 release, you must enable this feature again on the User Management Settings page.
This will make user management much easier, especially as new hires are onboarded or change jobs. For larger organizations, admins often spend a considerable amount of time doing this. By setting up these user policies, Salesforce can automate a lot of the assignments based on user criteria!
Align Fields Horizontally in Field Sections
Control field alignment across columns by using a new property on Dynamic Forms Field Section components. The Align fields horizontally property prevents fields in multicolumn Field Sections from collapsing upward when there’s a gap due to differences in field heights. Fields remain horizontally aligned with their neighbors in the same row. But even with this property selected, if a field is hidden because of visibility rules, the fields in its column still collapse upward to fill the empty space.
Where: This change applies to Lightning Experience in Group, Professional, Enterprise, Performance, Unlimited, and Developer editions.
How: To see the new property, click a Field Section component on a Dynamic Forms-enabled page in Lightning App Builder.
This should be done automatically! I bet almost every admin will check this setting on their page layouts!
Say Hello to Salutation Picklist Values in Lightning Experience
Streamline your workflow by managing Salutation picklist values in Lightning Experience. Use the Object Manager to add, delete, activate, deactivate, and replace Salutation picklist values. Previously, you switched to Salesforce Classic to modify them.
A nice-to-have that’ll save one from switching to Classic.
Boost Productivity with Mass Quick Actions on Related Lists (Beta)
Save your users time by decluttering the actions in the highlights panel and adding quick actions directly on related lists. Your users can create related records for items in the list without leaving the page. Or they can select up to 100 records in the related list and perform mass updates instead of single record updates.
Where: This change applies to Lightning Experience in Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
Note: This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.
How: You can add quick actions on a related list in one of two ways. Only Create a Record and Update a Record quick actions are supported in this release.
While the create Quick Action and Mass Update records are only supported for a related list, this will greatly improve the user’s experience working with child records! I look forward to custom actions being supported natively!
Synchronize Component Data Without a Page Refresh Using RefreshView API (GA)
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 Lightning web components (LWC) and Aura components. Previously, LWC lacked a data refresh API and could only refresh using an Aura wrapper and
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. This feature, now generally available, includes some changes since the last release.Where: This change applies to Lightning Experience in Enterprise, Unlimited, and Developer editions. Lightning Web Security (LWS) must be enabled in the Salesforce org.
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 supports refreshes that are triggered by end users or web components. RefreshView API provides a standard mechanism for data refresh experiences in LWC components, allowing flexible control of refresh scopes. RefreshView API can refresh data for Salesforce platform containers and custom LWC and Aura components. The base Lightning Aura components currently don’t support RefreshView API.
Lightning Locker doesn’t support RefreshView API.
This will be very helpful for developers to refresh the components on a page using a standardized LWC API without resorting to workarounds or creating an Aura component just for this. It’s also Generally Available in summer too! It does require Lightning Locker being enabled so one should try this out in a sandbox first and ensure everything still works.
Access Labels in Apex Dynamically
Use the System.Label.get(namespace, label, language) method to get a custom label, optionally specifying a language. The feature now allows dynamic resolution of label names at run time, including overriding the user’s current language if a translation exists for the requested language. Previously, retrieving labels required compile-time knowledge of the label API name.
This is very helpful for orgs have use multiple languages in use and they’d like to dynamically switch the text at run-time.
Use the Iterable Interface with Set Type
The Set class now implements the Iterable interface, so you can directly iterate over sets. Both sets and lists are iterable, allowing for more code reuse.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions. This change is a versioned change in API version 58.0 and later.
How: This example uses the String.join method with a Set, which was previously unsupported because Set didn’t implement Iterable.
Set<String> letters = new Set<String>{'a','b','c','d'};
System.debug(String.join(letters, '...'));Very nice! Another little improvement that makes developers more efficient by having to type less code!
Query Five Levels of Parent-to-Child Relationships in SOQL Queries
SOQL now supports relationship queries that traverse up to five levels of parent-child records. Use a single SOQL query to get parent-child records from five different levels. This ability is limited to SOQL queries via the REST and SOAP query calls on standard and custom objects.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
How: In API version 58.0 and later, SOQL relationship queries can contain a parent root as the first level of the query and child relationships up to four levels deep from the parent root.
This example SOQL relationship query returns records from the parent object Account and its child objects Contacts, Assets, WorkOrders, and WorkOrderLineItems.
This is awesome for those using the Salesforce REST & SOAP APIs to query data from Salesforce. Tools such as Workbench use those APIs to fetch data using SOQL queries. Once they have support, they can be used to fetch up to 5 levels of child records!
It’ll also be very helpful when Apex supports this which is hopefully on the roadmap!
Track the Publishing of Platform Events with Apex Publish Callbacks (Generally Available)
Get the final result of an EventBus.publish call through an Apex publish callback that you implement. After you receive the final publish result, you can decide what action to take, such as attempting to republish failed events. Because event publishing is asynchronous, the publish operation is queued in Salesforce. When no immediate errors are returned and when resources become available, the system
carries out the queued publish call. Without the callback, you can get only the intermediate queueing result in Database.SaveResult of an EventBus.publish call, not the final result.Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions.
How: To track failed event publishes, write an Apex class and implement the EventBus.EventPublishFailureCallback interface. If the asynchronous publish operation fails, the onFailure method is invoked. In the implemented onFailure method, you can write logic to act in response to the final result of the publishing operation. The result parameter contains the EventUuid
field values for each failed event, but doesn’t contain the data for the event. Use the getEventUuids method to correlate the failure results with the published events
public class FailureCallback implements EventBus.EventPublishFailureCallback {
public void onFailure(EventBus.FailureResult result) {
// Your implementation.
// Get event UUIDs from the result
List<String> eventUuids = result.getEventUuids();
// ...
}
}
This is very interesting. One often does not know the final outcome of a publish event so this capability lets one do something depending on if the event succeeds or fails. Most of the time some additional action is taken when the event fails. One could use this to implement “retry” logic, error notification logic, and others.
Get Enhanced Event Usage Metrics
Aggregate usage data by event name and determine which event is using up more of your allocations. Group usage by client to find out how many clients subscribed to a particular event and how your event delivery usage is shared among clients. Use granular time aggregations of daily, hourly, and 15-minute periods to slice and dice usage data. When you query PlatformEventUsageMetric, you can
use these new fields: EventName, Client, EventType, and UsageType.Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions. This feature isn’t available in Non-Hyperforce Public Cloud, Government Cloud, and Hyperforce instances.
When: This feature will be available in sandboxes when it becomes generally available.
How: Enhanced usage metrics is available in API version 58.0 and later after you enable this feature in Metadata API using PlatformEventSettings.This example query returns hourly event usage for delivered events from April 1 through April 2 in UTC time. The query aggregates the results into one-hour intervals as specified by the TimeSegment field. Results are grouped per event and client because the EventName and Client fields are specified in the SELECT statement.
SELECT EventName,
Client,
Value,
StartDate,
EndDate
FROM PlatformEventUsageMetric
WHERE TimeSegment = 'Hourly'
AND UsageType='DELIVERY'
AND StartDate >= 2023-04-01T00:00:00.000Z
AND EndDate <= 2023-04-02T00:00:00.000ZWith Platform Event Usage data, one can see where their events are originating and when and also when they aren’t being published and consumed. One can also use an analytics tool to consume this data to see how it’s trending over time.
Send Salesforce Data to an External Server Without Code via HTTP Callout (Beta)
If you can’t GET enough with HTTP Callout, now you can use the POST method to send Salesforce data to an external server in Flow Builder. Previously, only the GET method was available, which you can use to bring external data into Salesforce.
I’m happy one can build a POST HTTP request and send it to an external server. However, all the examples seem to show one using a public endpoint. Most endpoints are private and secure. One needs to authenticate first and then provide a security token in most instances. It’s unclear if this is supported or not. Additional research is needed to check. If you know, let me know in the comments!
Update the Screen In Real-Time using Formulas (Beta)
Working with supported formula functions, you can configure a screen component to perform real-time formula calculations and logic. When the flow detects a change in any of the values in the formula, it recalculates and updates the value of the screen component.
For example, the user sees a real-time screen update of a price discount, tax amounts, and shipping costs. Now it isn’t necessary for users to remember what they selected on a previous screen, thus less confusion and fewer clicks.Your existing flows only start displaying reactivity when you opt into the Beta program and explicitly save them with API version 57.0 and later.
Reactive Screen Flows! This will reduce the number of screens one needs since it’ll automatically update when different values are changed. Another feature that needs additional research. My stance is one shouldn’t use it in production though until it is Generally Available so try it out in a non-production org.
Use Email Templates in the Send Email Action
Reuse email content with Lightning and Classic email templates in the Send Email action. If your email template has merge fields, you can use the recipient record or a related record to populate the merge fields. Or, you can use both. Previously, you couldn’t use email templates in the Send Email action.
Where: This change applies to Lightning Experience and Salesforce Classic in Essentials, Professional, Enterprise, Unlimited, and Developer editions.
How: For example, to send an email to a contact using an email template with Contact and Account object merge fields, set Email Template ID to the ID of the email template to use (1). Then, set Recipient ID to the contact record’s ID (2) and Related Record ID to the related account record’s ID (3).
Finally! I can’t tell you how many times I’ve seen people using Text Templates and various workarounds to generate email content or use third-party actions to do this. Now with Email Template support, things are much easier and all those workarounds hopefully are no longer needed!
OAuth 2.0 Username-Password Flow Blocked by Default in New Orgs
If you create your org in Summer ’23 or later, the OAuth 2.0 username-password flow is blocked by default. The username-password flow presents security risks. We recommend using the OAuth 2.0 client credentials flow instead.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
Why: The username-password flow is blocked by default in new orgs so that developers can’t use it to build integrations. Blocking this flow is likely to break mobile applications, including those developed by Salesforce, such as the Salesforce mobile app and the Field Service mobile app. Blocking is also likely to break managed packages. You can monitor Login History to confirm if the username-password
flow is being used for a connected app in Salesforce. To avoid disruptions from blocking the username-password flow, you can enable the flow.How: To check if the username-password flow is being used for connected apps in Salesforce, create a Login History view and add the Login Subtype field. To enable the username-password flow, in OAuth and OpenID Connect Settings, select Allow OAuth Username-Password Flows.
With the new “OAuth 2.0 Client Credentials” flow, it is very easy to setup and does not expose the username and password so the user credentials aren’t shared. It’ll take time to adopt this new flow so it’s nice that Salesforce has an “Enable” setting to allow the Username-Password flow in new orgs as needed.
API Only Users Are Restricted from Accessing the User Interface via frontdoor.jsp
Salesforce forgot to disallow the API only users from bridging over using the frontdoor.jsp page and are not disallowing it in the Summer release.
Track File Usage in Near Real-Time with FileEvent (GA)
Files are a treasure trove of sensitive and important information. Use FileEvent and FileEventStore, now generally available, to track file previews, uploads, and downloads from the UI and API. And because file events support transaction security policies, you can take steps to proactively control how users interact with specific files.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Performance, Unlimited, and Developer editions where Event Monitoring is enabled.
Who: This change is available to customers who purchased Salesforce Shield or Salesforce Event Monitoring add-on subscriptions.
Another great security addition that lets one see who is uploading, downloading, and doing file previews from the user interface and the API. One can also control how users interact with specific files using transaction security policies.
This does require platform shield or Event Monitoring to be purchased.
Track API Usage for All API Versions
Use the API Total Usage event type to monitor details of requests made from all versions of the Platform SOAP API, Platform REST API, and Bulk API. Previously, this event type monitored usage through API version 49.0.
Where: This change applies to Enterprise, Performance, Unlimited, and Developer editions. This event type is available in the API but not in the Event Monitoring Analytics app.
Who: The API Total Usage event type is free with 24-hour data retention for all customers. Customers who purchased Salesforce Shield or Salesforce Event Monitoring add-on subscriptions enjoy a longer data retention period.
Since Salesforce is retiring more and more older API versions, this’ll help with identifying the Apps that need to be updated to support newer Salesforce API versions. This is one of the reasons why when I create a Salesforce client application, the API Version Number used in the Salesforce API Url is configurable so that it’s easily updated. I’ve never had a problem switching the API Version to a higher one for typical CRUD data operations.