I first published a release highlights post on this blog over 8 years ago; since that time the series has been renamed a few times but retained a focus on summarising the key technical aspects delivered with each release. I’ve always found preparing the content for the post a useful way to organise my own release readiness and feedback has indicated that amongst the plethora of release related blog posts available today there remains space for one with a technical slant. I hope so.

This post marks something of a relaunch to the series, this time with a strong focus on concerns significant to the Salesforce architect community (i.e. technical, solution or integration architects).

Release Timeline

Given the current global situation with COVID-19 the release timeline for Summer ’20 is approximately 1 month later than normal for a summer release. Each Salesforce release represents potential technical disruption for customers and managing this in parallel with the ongoing impact of the pandemic seems like an avoidable situation. The Summer ’20 sandbox preview is now scheduled for May 20-30th and the Summer ’20 production release is scheduled for June 12th (1st release window), July 10th (2nd) and July 17-18th *(3rd and final). As ever the trust site provides the full detail of the release timeline.

In advance of the sandbox preview window Summer ’20 pre-release orgs can be requested via the pre-release sign-up page. During the sandbox preview window Summer ’20 preview Scratch Orgs can be created by adding the release option (“release” : “Preview”) to the scratch org definition file.

The Salesforce Summer ’20 release notes are available from today at https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes

Architect Highlights (in no order)

Application Architecture

Record-Changed Flows

Previously Before-Save Flows could be implemented to efficiently update Record field values during the before-commit phase of the record save transaction; historically this has been a strong ApexTrigger use case. For many implementations a significant improvement in record-save performance could be achieved by consolidating Processes and before-event ApexTrigger logic into a single Flow. Refactoring Process Builder Processes which served to populate field values on the same record only could achieve a remarkable reduction in save time which in turn delivers a more responsive end user experience and a potential reduction in CPU timeout errors. With Summer ’20 Before-Save Flows are now Record-Changed Flows which support before-save and after-save events; equating to before or after ApexTrigger events. In the former case the Flow is restricted to field value updates (via $Record) but the latter enables a wider range of Flow actions to be utilised.

This new capability enables Workflows and Processes to be reimplemented following a single Flow pattern which should achieve the best performance outcome.

Platform Event Flows

Process automation initiated via Platform Event has been possible with Process Builder up to now, with Summer ’20 this is extended to Flow Builder. Platform Event Flows represent an obvious next step on the emergence of Flow Builder as the hub for all things process automation.

With this model it is possible to build out complex business logic (declaratively) in Flow Builder which fires in response to on-or-off platform asynchronous events; a powerful combination particularly in the data integration context.

Flow System Context

Flows which are specified to run in System Context (that bypass the permissions of the running user) can now run outside of the Sharing Model (effectively Without Sharing in Apex terms). Previously System Context was limited to removing Object and Field Access permission checks with the Sharing Model record-level access checks enforced by the Flow execution.

Apex-Defined Type Flow Variables

An Apex-Defined Type is simply an Apex Object typically representing deserialised JSON response in a data integration scenario. ADT variables could historically be utilised within Flows but could not be passed into the Flow from the calling context. With Summer ’20 it is now possible to hand-off callout response processing to a Flow, as one example use case. Whilst a seemingly minor change this opens up Flow as viable option for defining business logic for key use cases that would otherwise have required Apex code.

Dynamic Forms (Non GA Preview)

Undoubtably one of the most eagerly anticipated features for some time Dynamic Forms makes its preview debut in the Summer ’20 release. The Dynamic Forms feature is billed as an upgrade to Page Layouts where UI composition (sections, fields and visibility logic) occurs directly within Lightning App Builder. Preview support is limited to custom objects and excludes record pages that use pinned-region or custom page templates.

Lightning Message Service

The Lightning Message Service provides a standardised mechanism for communication across components on a page or across pages. Supported component types include Visualforce Pages, Aura Components and LWC. Communication is facilitated by Lightning Message Channel subscription and publication.

Development Lifecycle

Source Tracking in Sandboxes (Beta)

The source tracking deployment type is now supported for the developer sandbox types (Developer and Developer Pro); previously source tracking was restricted to Scratch Orgs. Source tracking enables efficient synchronisation of changed metadata between the local environment and the Salesforce org. Where existing development or release management processes (i.e. build automation and CI) are yet to be transitioned to Scratch Orgs this capability offers increased efficiency and accuracy as tracking of the changed metadata state is managed by the platform.

Org Dependent Unlocked Packages

Most Salesforce implementations suffer from a legacy accumulation of metadata components built up over a period of time by multiple projects, teams and partners. In such cases the benefits of implementing a structured Unlocked Package approach can appear to be unrealistic due to the degree of interdependency across the environment. With Org Dependent Unlocked Packages, metadata validation (i.e. dependency checking) can be deferred to the time of package installation, rather than during package version upload. Org Dependent Unlocked Packages can be created with the orgdependent Salesforce CLI parameter.

Security Architecture

Initiate Two Factor Authentication (2FA) with Apex

Two new methods have been added to the System.UserManagement class to enable Apex initiation of 2FA verification (e.g. Salesforce Authenticator). One method initiates a 2FA verification service (initVerificationMethod), the second completes the verification (verifyVerificationMethod).

Highly Trusted Users

The new “Skip Identity Confirmation at Login” permission allows users to login without second factor identity verification. Clearly one to use with a high degree of caution but useful for certain use cases where 2FA is impossible or impractical.

Minimum Access User Profile

The new “Minimum Access – Salesforce” User Profile provides a base profile for the Salesforce user license type defined following the principles of least privilege, a well-established security best practice. This profile can be cloned and extended as required or used in concert with Permission Sets. This support for a secure-by-default model feels long overdue.

Integration Architecture

Async Platform Event Publish Operations (Pilot)

The initial success of a Platform Event publication can be straightforward to determine (e.g. access to the SaveResult in Apex code) but the eventual state of the event is not accessible. To address this gap a new standard Platform Event (PlatformEventStatus) has been added; subscribers (e.g. ApexTrigger) are pushed status updates for High Volume Platform Events that have the “Track Publish Status” setting enabled.

Functional Architecture

Service Cloud. Omni-Channel Status-Based Capacity Model

Previously Omni-Channel tracked Agent capacity by the number of open tabs within the Agent Console. For short-lived Work Items (e.g. Case or Lead) that are resolved within a single user session the tab-based capacity model is often appropriate and can work well. However, this is not the case where Work Items are longer-lived and have a lifecycle that spans multiple user sessions or days: this leaves Omni-Channel a poor fit for many service operations. To address this Omni-Channel can now be configured to track Agent capacity based on the status of the Work Items that the Agent owns. The new Omni-Channel setting “Enable Status-Based Capacity Model” is used to switch between the default tab-based capacity model and the new status-based model. This could be a game changer for Omni-Channel given the importance of capacity management to service operations and the limitations of the tab-based model.

ISV

Delete Lightning Components from Managed Packages

A long awaited capability for ISV to delete obsolete Lightning Components from released Managed Packages. From personal experience I know how easy it has been over the last few years to build a legacy of old components in the package following refactoring and transition from Aura to LWC. Note, component deletion must be enabled in the Packaging Org (via Salesforce Support Case).

First Generation Managed Package Conversion (Developer Preview)

The Summer ’20 release includes a developer preview for the conversion of first-generation managed packages to second-generation managed packages. The preview is limited to Scratch Orgs and is intended to communicate how this long-awaited capability will function in due course. Personally, I’m looking forward to bringing the benefits of second-generation packaging to previously released managed packages.