Official: Platform Events

Hey Trailblazers 👋                                                                               

  Heads up: Standard-Volume Platform Events (SVPE) will be retired in Winter '27. If you've been    

  waiting for an easier path onto High-Volume Platform Events (HVPE), the new SVPE→HVPE migration

  tool is now available in preview sandboxes — and your migration clock has officially started.     

  The tool automates the heavy lifting of migrating your event definitions, Trigger and Flow

  subscribers, and downstream integrations from SVPE to HVPE — minimizing rework for both customers

  and AppExchange partners.

  ⏰ This tool is the supported path off SVPE before retirement.

  Why HVPE?

  - Longer event retention

  - More generous daily allocations and better scaling headroom

  - The forward path for event-driven architecture on the platform

  Where things stand:

  - ✅ Available now in your Preview (Pre-release) Sandbox

  - 🚀 Generally Available with the Summer '26 release (production rollout starts ~June 15, 2026)

  - 🛑 SVPE retires in Winter '27 — plan your migration accordingly                              

  What I'm asking of you:                                                                           

  1. Try it now in your preview sandbox — don't wait for GA.

  2. Tell us what worked and what didn't — especially edge cases, weird subscribers, or anything    

  else. All feedback is wanted.                                                                 

  3. ISV/Partner builders — Once you run it, your events will be updated, so you'll need to publish 

  a new package version for your downstream customers. Please run it against your managed packages 

  and share what you find, partner feedback is especially valuable here.                           

  📚 Docs: https://developer.salesforce.com/docs/atlas.en-us.262.0.api_tooling.meta/api_tooling/tooling_api_objects_platformeventmigration.htm

  💬 Reply in this thread with questions, findings, or issues — I'll be watching and responding     

  personally.                                 

I am successfully authenticating and able to subscribe just fine using PubSub API to the account platform event. 

Making unary calls with PublishAsync are successfully sending, i am receiving the replayId and CorrelationId back, however these platform events are not appearing. Interestingly Streaming Monitor creates the alert that an event has fired, however does not show up in the graph. 

I am triggering a simple flow using flow builder from this platform event which works fine when triggering via Apex/Streaming Monitor. I am getting flow errors. Error ID 712146348-203459 (1391829016) 

I am using Avro, basing my code from the Java and Go samples (there is no C# publishing sample - only subscribing) 

I have generated code using Avro.CodeGen from the schema retrieved from the GetSchemaInfoAsync endpoint from the proto file. I have spent a long time reading through the docs and code. The only thing i could find was 

https://developer.salesforce.com/docs/platform/pub-sub-api/guide/event-avro-serialization.html

"Pub/Sub API doesn’t validate the Avro format of the event payload that’s passed in to the 

Publish or PublishStream

 calls. It’s up to the client to make sure that the event payload is in Avro format and that it’s valid. The Publish and PublishStream calls complete successfully even if an event payload isn’t in valid Avro format. Because an event with an invalid payload fails to deserialize, a subscriber must filter out the events with invalid payloads." 

But i am unaware of way to debug this or validate. Im using  Avro.IO.BinaryEncoder which i believe is the same as the Java implementation. Any help would be greatly appreciated. Thanks. 

My week started well before my normal business hours seeing messages from a team from a very important downstream system that listens for CDC events from Salesforce. No events had been coming through. For hours. Checking the Salesforce limits showed we weren't close to any eventing limits, yet messages just weren't coming through, even when we made test changes to records that should be delivering CDC events.  

Ultimately a ticket with support returned the "Note that there is no defined SLA for CDC event delivery , and occasional delays are expected " which we'd seen before, but this time we also received:  

"CDC uses shared resource on instance & when other Org publish tons of events, other customers' org may run into events delivery delay 

We notice this phenomenon and continue to improve this performance issue." 

There was no issue listed on

and I was surprised to see a delay of this many hours.  

Questions I have: 

Have others experienced this kind of delay in eventing throughput?  

Do these delays only affect external subscribers or also Apex subscribers (which may make CDC as a method for asyncronous trigger logic problematic)? 

What's the longest delay we can expect to see when leveraging CDC? (Enough of a delay and it doesn't seem as "near real time" as we're normally used to.) 

CDC is built by Salesforce so is a shared service between customers. Would we have avoided this delay had we built on custom-defined triggered HVPE instead?  

Thanks much to anyone who is able to provide any clarity or additional experience and info. 

I'm working with Platform Events in Salesforce and have a question about how event delivery is handled with respect to heap size limits in Apex triggers. 

I understand the following: 

Each Platform Event can be up to 1 MB in size. 

An Apex trigger that subscribes to a Platform Event runs synchronously, and the maximum heap size for synchronous Apex transactions is 6 MB. 

It's possible to configure the batch size (e.g., 100) for a Platform Event subscriber via PlatformEventSubscriberConfig. 

Here’s my concern: 

If I publish 100 events, each of size close to 1 MB, and my trigger is configured with a batch size of 100, that would theoretically mean 100 MB worth of data is being delivered to a single trigger execution. But this clearly exceeds the 6 MB heap limit for synchronous Apex. 

❓ My question is: 

How does Salesforce handle this under the hood? 

Does the Platform Event delivery system automatically split the batch into smaller chunks that stay within the synchronous heap limit? 

Can I trust that the Apex trigger will never receive more events than it can handle without hitting heap size errors? 

Is there any official documentation or internal behavior description about how this batching/delivery mechanism works for large Platform Events? 

Thanks in advance for any clarification or resources!

Hey guys. Love the work.  

I want to let you all know of what appears to be a bug.  

Inspired by the awesome talk

gave at TDX London, I've been playing with parallel subscribers for an upcoming webinar. Cool feature.  

I've discovered that when I change the numPartitions value in PlatformEventSubscriberConfigs to anything other than 1, the Platform Event detail page in the Setup Menu gacks.  

This is in a Scratch org. And the basic behavior:  

1. Add a PE 

2. Add the PlatformEventSubscriberConfigs to define >1 partition (I've actually only tested with 3 and 10) 

3. For the record the PE also has partitionKey of EventUuid and a running user defined, but those don't seem to impact behavior.  

4. Changing numPartitions back to 1 resolves the problem.  

The page reports

.  

I've not had time to test on a different org type as of yet.  

Hello trailblazer 

I'm trying to find out if there's a way to determine whether MuleSoft is subscribed to a Salesforce Platform Event, and specifically, to see the last published ID and the last subscribed (processed) ID.

Is there a way to retrieve these details for internal subscribers?

Appreciate your help. 

And there I was, stopped in my tracks by a red error message: "Endpoint needs to be in full URL form". 

How did I get here? We've got to go back. Way back... about 10 entire minutes....

"I'm totally using the new Named Credentials for my new setup of Event Relays to AWS EventBridge. It's the way of the future!" I said eagerly.

After following the docs here on External Credentials for AWS, I found nothing about the URL for AWS. Back to the Event Relays doc, I saw only Legacy Named Credentials in the documentation.

"No, it'll be fine" I say to myself, and read:

"For URL, enter a URL in the format arn:aws:aws_region:aws_account_number. Replace the aws_region placeholder with your AWS region. Replace the aws_account_number placeholder with your 12-digit AWS account ID. The URL is case-sensitive, and aws_region is in capital letters. For example, the URL for an account in the US-WEST-2 region has this format: arn:aws:US-WEST-2:XXXXXXXXXXXX. (XXXXXXXXXXXX is a placeholder for the 12-digit AWS account ID.)"

I checked the Named Credential I used for my first AWS EventBridge integration to a different AWS account, and it matched. Confidently I entered the appropriate value (Account # changed in the screenshot for this post):

I clicked Save ready to celebrate quick success. And my hopes were dashed - shattered like a piece of cheap china tossed carelessly onto a tile floor.

The heartless words stare back at me still:  "Endpoint needs to be in full URL form"

I know this works with Legacy Named Creds - is the arn:aws URL format no longer supported with new Named Credentials?