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.

Introduction

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:

GET /services/data/v58/named-credentials/named-credential-setup

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:

Check out our Salesforce Developers Postman collection featuring the new Named Credentials APIs, and refer to the NamedCredentials Apex class documentation to learn more.

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 groupBy query argument and the ROLLUP or CUBE type
• 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:

If you’d like to give it a try, you can use the Altair GraphQL client or our Salesforce Developers Postman collection.

Salesforce Connect GraphQL adapter

Back in February 2023, we announced the pilot release for our Salesforce Connect GraphQL adapter, and now we are pleased to announce that it will be Generally Available in this Summer ’23 release.

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 EventUuid duplications.

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: EventName, Client, EventType, and UsageType.

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 EventName and 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, Order_Event__e and AccountChangeEvent.

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.

Learn MOAR

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.

Further Reading

• Release Highlights for Developers | Learn MOAR Summer ’23
• MuleSoft Innovations | Learn MOAR Summer ’23
• Tableau Innovations | Learn MOAR Summer ’23

About the author

Julián Duque is a Principal Developer Advocate at Salesforce where he focuses on Node.js, JavaScript, and Backend Development. He is passionate about education and sharing knowledge and has been involved in organizing developer and tech communities since 2001.

Follow him on Twitter @julian_duque, @julianduque.co on Bluesky, or LinkedIn.