Join us for Release Readiness Live this week! Product experts and developer advocates will discuss and demo new features in the Summer ’23 release, and at the end of our broadcast, we’ll be taking your questions. Tune in at 9 a.m. PT on May 19 for the developer session. Unable to join us live? The recording will be posted a few hours after the broadcast has ended.
Summer is finally here, and for us developers, that means an exciting new release! Let’s explore the upcoming features that the Summer ’23 release brings for developers focused on platform integration.
Nested SOQL queries in API
Starting with the Salesforce Platform API v58.0, SOQL now supports relationship queries that traverse up to five levels of parent-child records. Previously, only one level was supported. This feature is available for both standard and custom objects, and is limited to queries made through REST and SOAP query calls.
Let’s try it out by testing a four-level parent-child relationship using the REST API with the following query:
The API call now returns the requested nested records in the following hierarchy: Account (Level 1) → Contact (Level 2) → Case (Level 3) → Case Comments (Level 4).
Named credentials in Connect API
Another useful feature introduced in this release is the ability to manage named credentials from both the Connect REST API and the Connect API. You no longer need to interrupt your setup to create credentials through the UI; now, it can be done programmatically,
For example, you can retrieve the list of all existing named credentials by making the following API call:
Alternatively, you can use Apex with the following:
You can also create named credentials programmatically with both the API and Apex. Here’s an example of how to do so using Apex:
GraphQL API queries with aggregate functions
Our GraphQL API keeps getting better, and with this release, we are adding support for query records using aggregate functions with or without grouping.
You will be able to count the number of records that match certain criteria, calculate the average revenue on all accounts, or see the total amount of all opportunities.
The following aggregate functions are supported:
avg– Returns the average value of a numeric field
count– Returns the number of results matching the query criteria
countDistinct– Returns the number of distinct, non-null field values matching the query criteria
grouping– Specifies if a field is used when composing the group; use with the
groupByquery argument and the
max– Returns the maximum value of a field
min– Returns the minimum value of a field
sum– Returns the total sum of a numeric field
Let’s take a look at an example query. The following query calculates the average annual revenue of all the accounts, grouped by industry. Note that we are using the
aggregate field on
uiapi instead of
query, allowing us to take advantage of the aggregate functions.
Next, a GraphQL query using the average aggregate function and the grouping feature.
You can also perform traditional queries within the same request:
Salesforce Connect GraphQL adapter
The new Salesforce Connect adapter for GraphQL acts as a client to integrate data from external sources that expose their capabilities via GraphQL. It does so in a zero-copy manner by making live callouts to the API endpoints when a user or system action requires specific records. Only the data needed for that particular action is queried via GraphQL, and Salesforce Connect does not store or cache the records returned by the server. Additionally, this adapter includes special extensions for AWS AppSync, and provides seamless access to Amazon RDS.
To leverage this new adapter, simply create a New External Data Source and select the GraphQL type.
Apex publish callbacks on platform events
With the Summer ’23 release, you can now track the publishing of platform events using Apex Publish Callbacks. With this new release, you can obtain the final result of an
EventBus.publish call through an Apex publish callback that you implement. This gives you the option to track either failures or successes to receive the final publish result. Based on that result, you can then decide what action to take, such as attempting to republish failed events, for example.
To track a failed event published, write an Apex class and implement the
EventBus.EventPublishFailureCallback interface. If the asynchronous operation fails, the
onFailure method will be invoked. The
result parameter contains the
EventUuid field values for each failed event, but doesn’t include the data for the event itself.
To track successful event publishes, write an Apex class and implement the
EventBus.EventPublishSuccessCallback interface. Because most publish calls typically succeed, processing successful event publishes isn’t likely a concern. Always watch the performance and Apex governor limits when processing this type of result.
As a best practice, always create events using
sObjectType.newSObject, as this includes an
EventUuid that you can use to track the event. When creating events with this approach, we recommend not publishing the same event more than once to prevent
Enhanced metrics for platform events
With this update, you can now obtain enhanced event usage metrics for platform events by querying the
PlatformEventUsageMetric object. This enables you to aggregate usage data by event name and determine which event is consuming more of your allocations. Additionally, you can group usage by client to discover how many clients subscribed to a particular event and how your event delivery usage is distributed among clients. Also, use granular time aggregations of daily, hourly, and 15-minute periods to slice and dice usage data for deeper insights.
When you query
PlatformEventUsageMetric, you can use these new fields:
The following example query returns hourly event usage for delivered events between April 1 through April 2 in UTC time. It also aggregates the results into one-hour intervals as specified by the
TimeSegment field. Since the
Client fields are specified in the query, the results will be grouped per event and client.
A sample result of the previous query would look like the following, it will include usage data for all the events,
For more information about this feature please refer to the documentation.
HTTP Action in Flow: GET is GA, POST is Beta
HTTP Callout is now generally available for GET requests, which empowers you to bring external data into Flow Builder without any code. You create an HTTP Callout action from right within Flow, which can call out to any web-based service API. After you add the API details, Flow Builder generates a reusable callout action that you can use for different flows and across Salesforce.
To put it to use, from the Actions element, select Create HTTP Callout.
Along with GA, we’ve included some changes since the last release that streamline the configuration process.
You can now edit an HTTP callout action declaratively. APIs regularly change, for example, when a new required field is added to an external system. Previously, to edit the reusable HTTP callout action, you modified the autogenerated API specification, which required JSON skills. Now, you can edit the action with clicks in the External Services setup menu.
Configuring the API response’s data structure got simpler, too. You provide a sample API response, and Flow infers the data types and parses the JSON to make the data usable in flows. Previously, if you needed to change the inferred data types, you edited the JSON itself. Now, you select the field’s data types with clicks. Date, Date/Time, and Boolean data types are also now supported.
As an extra bonus, you get more intuitive error messages when building your HTTP callout action to help resolve the error and prevent issues at run time.
And If you can’t GET enough with HTTP Callout, now you can use the POST method (Beta) to send Salesforce data to an external server in Flow Builder. For example, a new account in Salesforce triggers a flow that creates an invoice in an external system. Select POST (Beta), enter a sample JSON request body that the API expects when configuring the HTTP Callout, and Flow infers the external data structure.
Wow, that’s quite a few new platform integration features to try out! I’m confident that they will make life easier for many developers. But there’s more to discover! I invite you to explore our other blog posts to learn about the latest updates for LWC, Mobile, MuleSoft, and Tableau.
Our product managers and developer advocates are back to share the latest features and functionality coming in Summer ’23. To help you develop faster, there’s a wealth of new content from the Developer Relations team covering their favorite new features. Be sure to check out Release Readiness Live on Friday, May 19th at 9:00 a.m. PST, and read the latest on the Salesforce Developers blog for more developer-related innovations in the Summer ’23 release!
Dig into Trailhead trailmixes with key release highlights for developers or admins, or both! Follow and complete a Learn MOAR Summer ’23 trailmix for admins or developers to earn an exclusive community badge.
- Release Highlights for Developers | Learn MOAR Summer ’23
- MuleSoft Innovations | Learn MOAR Summer ’23
- Tableau Innovations | Learn MOAR Summer ’23
About the author