Platform Event-Triggered Flows

Why Platform Event-Triggered Flows Matter

Most automation an administrator builds reacts to something that happens inside Salesforce: a record is created, a field is updated, a date is reached. But modern business processes rarely live in one system. An order might be confirmed in an ERP, a payment might clear in a banking gateway, a shipment might be scanned in a warehouse application, or a sensor might send a reading from the field. Salesforce needs a way to react to these events without a record necessarily being saved first, and without the publisher of the event needing to know anything about what happens next.

That is the role of Platform Events and, for declarative automation, Platform Event-Triggered Flows. They are the Salesforce implementation of an event-driven architecture: one system publishes a message to an event bus, and one or more subscribers react to it independently. For the Advanced Administrator exam, this topic sits in the Process Automation domain and tests whether you can recognise when an event-driven, asynchronous, decoupled solution is the correct answer rather than a traditional record-triggered flow, scheduled flow, or custom code.

What Is a Platform Event?

A platform event is a special kind of sObject that you define in Setup (Setup > Platform Events). Key characteristics to memorise:

• The API name always ends in __e (for example, Order_Shipped__e), just as custom objects end in __c.
• It has custom fields, but only a limited set of field types: Checkbox, Date, Date/Time, Number, Text, and Text Area (Long). No lookups, no formulas, no picklists, no roll-ups.
• Event records are not stored in the database and cannot be queried with SOQL, viewed in list views, or reported on. They are messages that flow through the event bus.
• Event messages are retained on the event bus for a limited time (72 hours for high-volume events) so subscribers can replay them using the ReplayId, but this is primarily relevant to API and Apex subscribers.
• Each event definition has a Publish Behavior setting: Publish After Commit (the message is published only when the publishing transaction successfully commits) or Publish Immediately (the message is published as soon as the publish call executes, even if the transaction later rolls back). Publish After Commit is the safer default for data-related processes; Publish Immediately is used for things like logging where you want the message even if the transaction fails.
• Platform events are high-volume by default in modern orgs, which gives higher publishing and delivery allocations.

Who Can Publish a Platform Event?

Publishing an event is simply creating a record of the __e object. You can publish from:

• A Flow, by using a Create Records element and choosing the platform event object. Any flow type can do this (record-triggered, screen, scheduled, autolaunched).
• Apex, using EventBus.publish().
• The REST API, SOAP API, or Bulk API from an external system (a POST to the sobjects endpoint for the __e object).
• External middleware and integration tools such as MuleSoft.

The publisher does not know or care who is listening. That decoupling is the whole point.

What Is a Platform Event-Triggered Flow?

A Platform Event-Triggered Flow is a flow type in Flow Builder that subscribes to a specific platform event. When a message of that event type arrives on the event bus, Salesforce launches an interview of the flow and makes the event message available inside it. It is the declarative equivalent of writing an Apex trigger on a platform event.

When you create a new flow and choose Platform Event-Triggered Flow, you select the platform event object that should start the flow. That event becomes the flow's trigger. The flow then appears in the Subscriptions related list on the platform event definition page, alongside any Apex triggers or other subscribers.

How It Works, Step by Step

1. Define the event. An admin or developer creates the platform event and its fields, for example Order_Shipped__e with fields Order_Number__c, Tracking_Number__c, and Shipped_Date__c.

2. Build the subscriber flow. In Flow Builder, create a Platform Event-Triggered Flow and choose Order_Shipped__e. The event message is exposed through the global $Record variable, so $Record.Order_Number__c returns the order number from the incoming message. These values are read-only; you cannot update an event message because it is not a stored record.

3. Use the event data. Typically the flow uses a Get Records element to find the related Salesforce record (for example, the Order whose number matches $Record.Order_Number__c), then uses Update Records, Create Records, Decision, Assignment, Loop, Action (send email, post to Chatter, custom notification, invocable Apex), or Subflow elements to carry out the business logic.

4. Publish the event. The external warehouse system calls the REST API to publish an Order_Shipped__e message. Alternatively, another flow or Apex class inside Salesforce publishes it.

5. The flow runs. Salesforce delivers the message to every active subscriber. A flow interview launches for each event message received, executes in the background, and finishes without any user interaction.

Important Runtime Characteristics

These are the facts most likely to appear as distractors or correct answers on the exam:

• Asynchronous execution. The flow runs in a separate transaction from the publisher, after the message is delivered. The publisher is never blocked waiting for the subscriber to finish, and the subscriber's governor limits are separate from the publishing transaction.
• Running user. The flow runs as the Automated Process user, not as the user who published the event. Consequences: records created or updated by the flow show Automated Process in Created By or Last Modified By, emails sent appear to come from the Automated Process user unless you configure an organisation-wide email address, and user-specific context such as $User does not reflect a human user.
• System context without sharing. The flow can access and modify all records regardless of the sharing model, because there is no running user whose sharing rules would apply. This is powerful but means you must be deliberate about what the flow is allowed to do.
• No user interface. Platform event-triggered flows cannot contain Screen elements, and they do not support Pause elements. If you need to wait or interact with a user, publish a different event or use another flow type.
• No entry conditions on the trigger. Unlike record-triggered flows, you cannot filter at the trigger level. If the flow should only act on certain messages, place a Decision element as the first step and route unwanted messages to an End.
• Mixed DML avoidance. Because the subscriber runs in its own transaction, publishing a platform event is a recognised technique to avoid Mixed DML errors, for example when a record change needs to update a User, Group, or other setup object in the same process.
• Error handling. If the flow fails, the error is reported through the standard flow error email (to the admin or the Apex exception email recipients) and the flow interview for that message ends. The event message is not automatically retried by a flow the way an Apex trigger can request a retry. Use Fault paths on data elements to log or notify when something goes wrong.
• Testing. You cannot simply press Run as you would with a screen flow. To test, you must actually publish an event message: build a small screen flow or autolaunched flow that creates a record of the __e object, use Developer Console anonymous Apex with EventBus.publish(), or use Workbench or the REST API. Then verify the results (records updated, emails sent, debug logs for the Automated Process user).
• Activation. Like any flow, it must be Active to subscribe. An inactive platform event-triggered flow receives nothing, and messages published while it is inactive are not processed when it is later activated.

Platform Event-Triggered vs Other Flow Types

The exam loves to present a scenario and ask which flow type fits. Use this quick comparison:

• Record-Triggered Flow: starts when a record is created, updated, or deleted in Salesforce. Supports before-save and after-save, entry conditions, and scheduled paths. Use when the trigger is a data change in the org.
• Schedule-Triggered Flow: starts at a specified time and frequency for a set of records. Use for batch or nightly processing.
• Autolaunched Flow: has no trigger of its own; it is called by another flow, Apex, a button, or an API. Use for reusable logic.
• Screen Flow: requires user interaction.
• Platform Event-Triggered Flow: starts when an event message is received. Use when the trigger originates outside Salesforce, when you need to decouple the publisher from the subscriber, when you need asynchronous processing in a separate transaction, or when multiple independent subscribers should react to the same business event.

Also distinguish platform events from Change Data Capture (CDC). CDC events are published automatically by Salesforce when records change and are consumed by external systems or Apex; you do not define their fields. Platform events are custom-defined messages you publish deliberately. A flow subscribes to platform events, not to change events.

Common Real-World Scenarios

• An external logistics system publishes a Shipment_Delivered__e event; a flow finds the matching Order, sets its status to Delivered, and sends a confirmation email to the customer.
• A payment gateway publishes a Payment_Received__e event; a flow updates the Opportunity to Closed Won and creates a Task for the account manager.
• A record-triggered flow on Case publishes a Case_Escalated__e event; one subscriber flow posts to Chatter, while an Apex subscriber pushes the alert to an external paging system. Adding a third subscriber later requires no change to the publisher.
• A record-triggered flow needs to deactivate a User when a Contact is marked as departed. Doing the User update directly would raise a Mixed DML error, so the flow publishes an event and a platform event-triggered flow performs the User update in a separate transaction.
• Error logging: a flow publishes a Flow_Error__e event with Publish Immediately behaviour from a fault path, and a subscriber flow writes an error log record. Because of Publish Immediately, the log is written even though the original transaction rolled back.

How to Answer Exam Questions on Platform Event-Triggered Flows

Exam questions in this area are scenario-based. The skill being tested is pattern recognition: spotting the clues that point to an event-driven solution and eliminating distractors that describe the wrong flow type or the wrong runtime behaviour. Work through questions with this method:

1. Identify where the trigger originates. If the scenario says a change happens in an external system, a third-party application, middleware, or an integration, and Salesforce must react, think platform events. If the trigger is a Salesforce record being saved, think record-triggered flow instead.

2. Look for decoupling and scalability language. Phrases like without the publishing process needing to know about downstream actions, multiple systems need to react to the same event, loosely coupled, or event-driven are strong signals.

3. Look for asynchronous or separate-transaction requirements. Should not slow down the save, should run in the background, Mixed DML error, or needs its own governor limits all point toward publishing an event and processing it in a platform event-triggered flow.

4. Check the constraints of the flow type. If an answer suggests a platform event-triggered flow that shows a screen, pauses for approval, uses entry conditions on the trigger, or runs as the current user, it is wrong. If the scenario requires user interaction, a screen flow or a different design is needed.

5. Remember the running user. Any question about Created By shows Automated Process, emails come from an unexpected sender, or the flow can see records the user cannot is describing the Automated Process user and system context without sharing.

6. Know the declarative-first preference. If both an Apex trigger on the platform event and a platform event-triggered flow could satisfy the requirement, the Advanced Administrator exam generally favours the declarative flow unless the scenario explicitly demands something only Apex can do, such as retrying failed messages or complex batch handling.

Exam Tips: Answering Questions on Platform Event-Triggered Flows

• Tip 1: The suffix __e identifies a platform event. If you see an object name ending in __e in an answer, you are looking at an event, not a custom object or external object.
• Tip 2: Platform events are published with a Create Records element in Flow. There is no special Publish element. An answer that says use Create Records on the platform event object is describing publishing correctly.
• Tip 3: The subscriber flow reads event data from $Record, and those values are read-only. You cannot use Update Records on the event message itself.
• Tip 4: Platform event-triggered flows run asynchronously, in system context without sharing, as the Automated Process user. Memorise these three attributes together; questions often test exactly one of them.
• Tip 5: No Screen elements, no Pause elements, no trigger-level entry conditions. Use a Decision element for filtering.
• Tip 6: Publish After Commit means the subscriber only hears about the event if the publishing transaction succeeded. Publish Immediately delivers the message even if the transaction rolls back, which is ideal for error logging.
• Tip 7: Platform events are a standard remedy for Mixed DML errors because the subscriber runs in a separate transaction.
• Tip 8: Event messages cannot be queried, reported on, or seen in list views. If a scenario needs a persistent record of each event, the subscriber flow must create a regular record to store it.
• Tip 9: To test, you must publish a real event message. Debugging a platform event-triggered flow directly in Flow Builder is not the normal approach; expect answers involving a helper flow, anonymous Apex, or an API call.
• Tip 10: The flow must be Active to subscribe. Messages published while the flow is inactive are missed by that flow.
• Tip 11: Distinguish Platform Events (custom-defined, published deliberately, can trigger flows) from Change Data Capture (automatic change notifications for records, consumed by external systems or Apex, not a flow trigger).
• Tip 12: When a question asks for the most scalable or most maintainable way to let several independent processes react to one business event, the answer is almost always to publish a platform event and have each process subscribe, rather than chaining updates through a single record-triggered flow.
• Tip 13: Watch for distractors that propose a Schedule-Triggered Flow polling for changes from an external system. Polling is less efficient than event-driven integration; if real-time or near-real-time reaction is required, platform events are the better answer.
• Tip 14: Use Fault paths in the subscriber flow for error handling. Platform event-triggered flows do not automatically retry failed messages; an answer that assumes automatic retries in a flow is incorrect.

Summary

Platform Event-Triggered Flows let administrators build event-driven, loosely coupled, asynchronous automation without code. A platform event is a custom message (object API name ending in __e) published to the event bus by a flow, Apex, or an external system. A platform event-triggered flow subscribes to that event, launches once per message, exposes the message data through $Record, and runs in the background as the Automated Process user in system context without sharing. It cannot show screens, pause, or filter at the trigger level, and it runs in a separate transaction from the publisher, which makes it the ideal tool for external-system integration, multi-subscriber notifications, background processing, and avoiding Mixed DML errors. On the exam, read each scenario for clues about the origin of the trigger, the need for decoupling or asynchronous processing, and the runtime constraints of the flow type, and you will consistently select the correct answer.