Skip to content

Events

Chapter 11 of Integration Architect, Part 2: Designing Integrations That Work (Design). Previous: Moving Data at Scale · Next: Keys, Certificates and Trust.

There are three ways for another system to get the news from Salesforce. Salesforce can call it. It can keep calling Salesforce to ask, “anything changed?” Or it can call once and stay on the line, and hear each change the moment it happens. That third way is events.

And it’s why so many people get the arrows reversed. The news goes out of Salesforce, so the arrow looks like it points out. But the subscriber dialed. It keeps the line open, it calls back when the line drops, and it says where to pick up. Salesforce publishes and moves on. The clients connect in, and the data goes out.

This chapter is the rest of that idea: the bus the events travel on, the two kinds of news, how a subscriber catches up, what the platform counts, what happens inside the org, what happens beyond it, and how you write down what an event promises. Steve Trucking runs through every module: Delivery Update to the integration layer, Work Order changes to Snowflake, and three partners who each want the status their own way.

  • The subscriber dials and stays on the line. The arrow points from whoever starts the call, so on a landscape it points into Salesforce. The subscriber owns the connection, the reconnection and the error handling.
  • One in, many out. An event goes on the bus once, and every subscriber hears it. The Pub/Sub API is the modern line onto the bus: the subscriber says how many it can take, and keeps its own place, or lets Salesforce keep it.
  • Two kinds of news. A platform event is news you design and publish when the business says so. A change event is news Salesforce publishes for every change on the objects you select. A filtered channel turns the flood into only the changes a subscriber needs.
  • Pick up after the last one handled. Events wait 72 hours. Store the replay ID after the work is done, and be ready for the same event twice, events out of order, and a gap older than 72 hours.
  • Count deliveries, not events. Publishing and delivery are metered separately. Every outside subscriber’s deliveries are counted; flows and triggers inside the org aren’t. Steve Trucking is over Enterprise Edition’s allocation on day one.
  • Inside the org, an event is a new transaction. A fresh set of limits, and two saves that can’t be one. A flow or a trigger: who it runs as, how many it takes, and how it fails.
  • Not on our bus. Systems that talk among themselves get a backbone of their own, Kafka or a cloud’s. Salesforce joins it over a bridge: middleware, Event Relay, or a connector.
  • The publisher writes the contract. AsyncAPI is the contract, written once. CloudEvents is the label on every event. A version is a promise, and more so when you can’t see who’s listening.

Eight modules, each standing on its own.

  1. The Reversed Arrow. Three ways to get the news; when the line drops; who does what; why people get the arrows reversed; still outbound, arrow pointing in.
  2. The Event Bus and the Pub/Sub API. One in, many out; events aren’t records; on the line, call by call; who keeps your place; a stream, not a queue; your lab bench.
  3. Platform Events and Change Data Capture. Two kinds of news; when it actually leaves; just turn it on; what a change event carries; gap and overflow events; from a tsunami to a stream.
  4. Replay, Retention, Order. How long they wait; three places to pick up; keeping your place; again, out of order, too late; when Salesforce moves your org.
  5. Allocations. Two meters; inside is free; every subscriber counts; the constraints match; spend fewer deliveries; when you run out; watch the meter.
  6. Events Inside the Org. A new transaction; mixed DML, two saves with an event between; a flow or a trigger; who it runs as, how many, when it fails; more than one stream.
  7. Beyond the Bus. Not on our bus; the backbones outside; three bridges; the size gap, dated; the older doors.
  8. The Contract and the Envelope for Events. Who writes the contract; AsyncAPI, OpenAPI’s twin; Salesforce’s own schema; CloudEvents, the label on the box; a version is a promise.

Chapter 12 takes the trust underneath every one of these lines: keys, certificates and the handshake. Chapter 13 then takes who the subscriber is, how it proves it, and what it’s allowed to hear.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

  • For each piece of news: an event or not, and which kind: a platform event for a business moment, Change Data Capture to copy what changed.
  • Each event’s publish setting, and what goes in it: the whole package or just the ID.
  • Where every subscriber picks up after a drop, who keeps its replay ID, and how it handles a repeat, an event out of order and a gap past 72 hours.
  • The delivery count for the whole org, every event times every outside subscriber, today and at year three, and how to bring it under: filters, one subscriber that fans out, or the add-on.
  • For each subscriber inside the org, a flow or a trigger, its running user, its batch size, and how it fails.
  • Which bus each piece of news belongs on, and the bridge for each event that crosses.
  • Each event’s contract: its owner, what it promises beyond the schema, and how it changes.

Beyond the exam: an AI assistant will write the subscriber in an afternoon: connect, subscribe, decode, process. What it won’t decide is where the subscriber picks up when the line drops, what it does with the same event twice, or whose deliveries are counted against whose allocation. Those decisions are this chapter.

Next: Keys, Certificates and Trust