The most commonly used traditional approach to build integrations is via batch/future/queueable features that uses request-response communication model. Mostly, the request will be sent to the server and wait for the response.

Summer 17 release has introduced a cool way to build nearly real-time integrations via the concept of platform events. This uses a publisher-subscriber model.

Publisher—a sender broadcasts a message that one or more receivers capture.

Subscriber – a receiver captures the message whenever an event is available in the channel. Receivers don’t acknowledge it when they receive an event.

Event-driven model decouples event producers from event consumers. This is suitable for the integrations where the systems that send events and others that receive the events don’t have dependencies on each other.

How to setup Event:

Platform events are special custom objects in salesforce and you create a platform event definition by giving it a name and adding custom fields (only few set of fields are supported). We can’t update or delete event records or view event records in the Salesforce user interface. The API name suffix ends with __e. Sample definition could be:

Event publishers/subscribers can be defined inside/outside salesforce and can be used in three directions:

  1. Platform to External app: Salesforce acts as a publisher and external system as a subscriber. Eg: On change of a record to certain value, you publish an event to notify the change. The external system can subscribe the event there by receiving the notification from the event channel via API.
  2. External app to Platform: External system acts as a publisher and salesforce as a subscriber. Eg: External system can notify the salesforce by publishing events via API and the salesforce can subscribe and fetch related info via event object apex trigger.
  3. Platform to Platform: Salesforce acts as both publisher and subscriber. Eg: A custom object apex trigger can publish the event and the event object apex trigger can perform actions based on the published data.

How to publish:

  1. Salesforce:

Within Salesforce, we can publish the events by creating event object instances like any Sobject.

Cloud_News__e newsEvent = new Cloud_News__e(
                               Location__c='Mountain City', 
                         News_Content__c='Lake Road is closed due to mudslides.');
List<Database.SaveResult> results = EventBus.publish(newsEvent);

We can also use process builder to create events by selecting “Create record” as an action.

  1. External system:

We can create event object records by common APIs like REST, SOAP, BULK.

How to subscribe:

Event can be subscribed in following ways:

  1. Salesforce:

Write an after insert Apex trigger on the event object to subscribe to incoming events. Platform events support only after insert triggers.

// Trigger for listening to Cloud_News events.

trigger CloudNewsTrigger on Cloud_News__e (after insert) {         

// Iterate through each notification.

    for (Cloud_News__e event : Trigger.New) {

        // perform some action using event instance



We can also use process builder to create a process that starts when a platform event occurs.

  1. External system:

External apps subscribe to platform events by using streaming API with CometD and perform long polling. Platform apps, such as Visualforce pages and Lightning components, can use CometD as well.

Event’s behavior:

Platform events are non-transactional; it isn’t processed within database transactions in the Salesforce platform. As a result, published platform events can’t be rolled back. Majority of the cases in integration, we prefer asynchronous approach using future/schedulable batch approach. Due to the non-transactional behavior, platform events are always processed asynchronously and is one of the reasons to be suitable for integrations.

Platform events over Future Apex:

Future method supports only primitive data types in a method and writing complex logic can be difficult. Whereas platform events publishing is like Database insert; carrying the information would be easier due to custom fields support.

Platform events over Schedulable batch:

If you would like to process huge records from a trigger with complex logic, there is always a chance for hitting apex limits related to cpu time. One can think of isolating the complex logic from trigger and running in asynchronous fashion. We can opt for frequently (say, every 10mins) scheduling batch to process such records to make it nearly real time like trigger. However, opting platform events and apex event object triggers can provide same effect. One main advantage is that there isn’t a need to unnecessarily frequent check as the case with frequent schedulable batch. The subscriber only processes the platform events when a published event is put into the event channel.