Salesforce Pub/Sub API is the secret sauce to building asynchronous, event-driven integrations leveraging the Salesforce Platform and Change Data Capture events. Built with a modern outlook, it’s a gRPC-based API that went GA in June 2022. Being the single interface to publish and subscribe, this API allows you to take advantage of the real power of the Salesforce Event Bus and eventing platform in general. You can use Pub/Sub API to receive and send notifications via platform events, monitor your Salesforce org using real-time monitoring events, make data sync decisions based on Change Data Capture events, and get event schema.

Here’s a quick overview of Pub/Sub API strengths and capabilities:

• Supports Standard and Custom platform events, real-time monitoring and Change Data Capture events, and GETevent schema — all in one API
• Allows bidirectional streaming of events using HTTP/2 for faster performance
• Customers write Pub/Sub API clients using any of the gRPC-supported programming languages
• Clients use proto files and Avro libraries to encode and decode the event payloads
• Real-time publish acknowledgments

You can get started with learning the API and using the prebuilt code examples to get a quick start on building your next integration solution. There’s also a demo app that you can use to understand an end-to-end sample LWC application that is built using Pub/Sub API.

Managed Subscriptions (Beta) make subscribing with Replay IDs effortless

The Salesforce Event Bus has a three-day retention window, meaning that high-volume events, including platform and Change Data Capture events, are available in it for 72 hours. So, a client can resume subscription anytime and process events in the past going up to three days. A client can subscribe using one of three subscription options:

• Earliest: Subscribing from the earliest retained event, which can lead to duplicate events and extra processing
• Latest: Subscribing from the tip of the stream, starting with the latest event, which can lead to missed events
• Custom (Replay ID): Using the event’s Replay ID to subscribe back from where you left off

Custom is the most efficient and recommended way of subscribing as it ensures that you don’t miss any events and reduces any duplicity in processing. However, using the Custom option entails that the customer/client build and maintain their replay store to commit and track the last Replay ID and use that to re-subscribe.

With the latest feature of Managed Subscriptions releasing as an Open Beta in Summer ’24, Salesforce will maintain the replay store, and manage and track the Replay ID for the clients on the Pub/Sub API side. Clients can now build efficient solutions and rely on the Replay ID option without the overhead of maintaining their own replay store, and it can be truly stateless. You create a managed subscription with the Tooling API and then commit the Replay ID of the last event you processed in your external system with the new ManagedSubscribe RPC method. Let’s examine how to set up this configuration and use the new method.

Note: This feature is a Beta service. Customers may opt to try such Beta services at their sole discretion. Any use of the Beta service is subject to the applicable Beta service’s terms provided at Agreements and Terms. Make sure that you are using the updated proto file that supports the new RPC method of ManagedSubscribe.

Imagine that you have to set up a lead generation pipeline for your company, and you want to get notified of any changes to the Lead object’s data to be able to act on it in a timely manner. To get started, the first step is to enable Change Data Capture on the Lead object in your org. Let’s call this LeadChangeEvent.

Setting up a managed subscription

Use the Tooling API to create a one-time setup ManagedEventSubscription metadata configuration that will be used to store and commit the Replay ID to the Salesforce replay store. You can read more about the metadata type in the documentation. You can use any client to do so, and here we are using the Postman Collections client. Let’s call this managed subscription Managed_Sub_Lead.

This managed subscription configuration will be used to subscribe to the event channel.

Subscribing via the new RPC method

Once the metadata configurations are set up, you can now use the ManagedSubscribe RPC method to subscribe to LeadChangeEvent using Managed_Sub_Lead as a call parameter to start getting notified of any changes on the Lead object. Once subscribed, you will start receiving lead change events that you can begin processing. After receiving the batch of events, you can send a commit request to store the Replay ID of the last processed event. Then if you disconnect and reconnect later, the managed subscription resumes after the stored Replay ID.

Let’s say you created a lead, and marked their Lead status as “New – not contacted.” These show up as change events.

Now, when you are ready to receive and process events again, you resume the subscription using the same managed subscription Managed_Sub_Lead that you created for the LeadChangeEvent earlier.

A few minutes later, you change the Lead status to “Working – Contacted” and also update its first name. All of this was done when the subscription was disconnected. So, on resuming the subscription, both change events are received.

Take a deeper dive into managed subscriptions

Let’s get a little bit more technical and understand what goes on behind the scenes of the feature. Here’s a diagram that shows the flow of events when using managed subscriptions.

Now, let’s try to understand the flow of events in the diagram above. Pub/Sub API is a pull-based API, which means that the client can request events from the server when it is ready to process them, and the server will respond to that request with events if events are available. When a client subscribes using the ManagedSubscribe RPC method, it sends a ManagedFetchRequest to the server with the name of the managed subscription and the requested batch size. The server responds by sending a ManagedFetchResponse with the batch of events requested. Once the entire batch of events is delivered, another ManagedFetchRequest is sent from the client that now contains the CommitReplayRequest to commit the last processed Replay ID. The server then commits the Replay ID to the replay store and sends another ManagedFetchResponse back to the client with the CommitReplayResponse. The client can now disconnect if they want, or continue receiving more events.

On resuming the subscription, the client once again sends a ManagedFetchRequest to the server. The server then resolves the Replay ID from the replay store, and resumes sending events starting from the event after the one with the stored Replay ID, to the client along with ManagedFetchResponse.

This is how Salesforce manages and keeps track of the Replay ID of the last event you processed and lets you jump back onto the bus from the same point! You can now use the Custom subscribe option (using Replay ID) while focussing on processing events without having to worry about resolving Replay IDs or writing a single line of code to do it.

Conclusion

In this blog post, you learned about the brand new Managed Subscriptions (Open Beta) feature, and how it allows you to integrate with the Salesforce Event Bus in the most efficient manner using Replay IDs, while being stateless on the client end.

So, get started and leverage Pub/Sub API to harness the magic of Salesforce Events and the Event Bus, and share your feedback with us. Awesome customers like you who are passionate about Salesforce help us make our products better thanks to your opinions. Please share them with us via the recommended Trailblazer Community channels for Change Data Capture or Platform Events. Alternatively, you can report issues and provide feedback to us on our GitHub repo for Pub/Sub API.

About the Author

Neha Ahlawat is a Product Management Director in the Einstein 1 Platform organization at Salesforce, where she’s focused on the product areas of Metadata API, Tooling API, source tracking, and change sets. Follow her on X and LinkedIn.