Event Studio
Event Studio is a Salesforce Setup area that provides administrative tools for designing, monitoring, and managing the event-driven messaging features of the platform: Platform Events, Change Data Capture events, Flow Orchestration events, and the supporting infrastructure for subscriptions, channels, and replay.
Definition
Event Studio is a Salesforce Setup area that provides administrative tools for designing, monitoring, and managing the event-driven messaging features of the platform: Platform Events, Change Data Capture events, Flow Orchestration events, and the supporting infrastructure for subscriptions, channels, and replay. It overlaps in scope with Event Manager and the various event-monitoring pages, with Event Studio acting as the design-and-build surface where admins create new event types, define their fields, and configure subscriber rules.
The page is the right starting point for anyone building a new event-driven integration on Salesforce. Where Event Manager surfaces operational metrics (publish rates, subscriber lag, throughput consumption), Event Studio is the configuration surface where admins design the event itself. The two surfaces work together: Event Studio for the build phase, Event Manager for the operate phase. Mature event-driven deployments use both routinely, with admins moving between them as they iterate on new events and monitor production traffic.
What admins build in Event Studio
Defining Platform Event types
From Event Studio, admins create new Platform Event types similar to creating custom objects: name the event, add fields with types, set retention behavior, and define publishing controls. Each Platform Event becomes a queryable channel that Apex, Flow, and external systems can publish to and subscribe from. The fields define the event's payload shape. Common fields include the related record ID (linking the event to a specific Account, Case, or Opportunity), a timestamp, an event type code (for events that carry multiple sub-types), and any custom business data the consumers need. Designing the event shape thoughtfully matters because subscribers will build against this shape; changing it later is a version-management exercise.
Configuring publishing controls
Event Studio lets admins control who can publish events of each type. The default is that any user with API access can publish; tighter restrictions can be configured per event type, allowing only specific profiles or integration users to publish. The publishing controls work alongside the throughput limits to govern who can use a given event channel and how often. For high-value events (a Customer Churned event that triggers expensive downstream automation), restricting publishing to specific users prevents accidental over-firing from a runaway test script or a misconfigured Flow.
Subscriber registration and management
Subscribers to an event include Apex triggers, Flow listeners, and external systems consuming via streaming or Pub/Sub APIs. Event Studio surfaces the current subscriber list for each event channel: which Apex triggers are listening, which Flows are configured as subscribers, which external systems are connected. The page lets admins enable or disable subscribers without rebuilding the underlying code, which is useful during incident response when a misbehaving subscriber needs to be paused without code deployment.
Channel grouping for related events
Beyond single-event subscriptions, Event Studio supports custom Channels that group multiple event types into one subscription target. An integration that consumes both Account changes and Opportunity changes can subscribe to a single Channel containing both Platform Events plus the corresponding CDC channels, rather than maintaining separate subscriptions. The Channel concept reduces consumer-side code complexity and improves subscription efficiency. Admins configure Channels in Event Studio by selecting the constituent events; the consumer then subscribes to the Channel by name and receives every event from any constituent channel.
Replay and retention configuration
Each event channel has a retention window (typically 72 hours for Platform Events, 24 hours for CDC) during which subscribers can replay missed events. Event Studio surfaces the retention setting and shows the current replay state for each subscriber. A subscriber that has been offline can request events from a specific replay ID to catch up, as long as the requested ID is within the retention window. Past the retention window, events are dropped and cannot be recovered. The retention setting is platform-defined and not customer-configurable, but Event Studio is where admins see how close subscribers are to the retention edge.
Testing and event simulation
Event Studio includes tools for testing event flows without involving a production system. Admins can simulate publishing an event with specific field values and observe how subscribers process it. This is useful during development of new event-driven integrations: rather than wiring up a producer system to test a subscriber, the admin publishes a test event from Event Studio and watches the Apex trigger or Flow respond. The simulation respects all the normal subscriber rules, so a test event behaves exactly like a production event for the purpose of the test.
Audit and governance
Every event-definition change made through Event Studio is logged in Setup Audit Trail with the user, timestamp, and the action taken. For organizations with strict change management, this audit trail combined with the event-publishing audit (which event was fired by whom) provides a complete picture of the event-driven system's lifecycle. Mature deployments build dashboards that cross-reference Event Studio configuration changes with Event Manager operational metrics, surfacing patterns like "we added a new subscriber two days ago and now the publish rate doubled."
Event Studio versus the broader Salesforce automation toolkit
Event Studio sits alongside several other automation tools that overlap in scope: Flow Builder for declarative automation, Apex for code-based automation, the standard Workflow Rule (deprecated for new automation), Process Builder (also deprecated), and the various integration toolkits like External Services and MuleSoft. Each tool has its right place. Event Studio is the right answer when an integration needs real-time event delivery to multiple subscribers, when the publisher and subscriber are decoupled by design, or when the same event might be consumed by both internal and external systems. Flow Builder is right for simple record-triggered automation with one subscriber and synchronous behavior. Apex is right for complex logic or high-throughput processing. External Services is right for outbound REST calls. The senior architect on the team should be able to articulate the boundaries clearly and steer each new automation request to the right tool. Without that discipline, orgs end up with a confusing mix of overlapping automations that each handle similar use cases differently, which becomes painful to maintain three years later. Event Studio earns its place when the use case truly benefits from event-driven decoupling, not when it is just a fashionable choice for what could have been a simple Flow.
Adoption patterns and starter use cases
Three starter use cases work well for teams new to event-driven architecture on Salesforce. The order-completed event published when an order moves to a final status, with subscribers in the warehouse system and the customer-notification system. The customer-tier-changed event published when a customer crosses a loyalty threshold, with subscribers in marketing automation and the loyalty program dashboard. The case-escalated event published when a service case crosses an escalation rule, with subscribers in the management notification system and the case-assignment-routing system. Each of these is a real business signal that benefits from multiple decoupled subscribers, which is exactly what event-driven architecture excels at. Starting with these patterns gives the team practical experience before tackling more complex scenarios like saga orchestration or event sourcing. Mature event-driven orgs operate dozens of event types across their automation stack, each one carrying a specific business signal that one or more subscribers act on independently.
Design and deploy a Platform Event through Event Studio
Creating a Platform Event through Event Studio is a four-stage flow: design the event shape, register it in the org, configure subscribers, and validate end-to-end. The walkthrough below covers a typical use case where a custom business event needs to trigger downstream Apex and Flow automation plus notify an external system.
- Design the event shape and consumers
Document what the event represents (an Order Shipped event, a Customer Tier Upgraded event), what fields it should carry (the order ID, customer ID, timestamp, any business-relevant data), and what consumers should receive it. Identify which consumers need real-time delivery and which can tolerate slight latency. Confirm the event is not better served by a Change Data Capture event on an existing object; custom events are right for business signals, not for general data replication.
- Create the Platform Event in Event Studio
From Setup, navigate to Event Studio and click New Platform Event. Provide the event name, plural label, and the fields with their types. Set the publishing controls to restrict which users can fire the event. Save. The Platform Event now exists as a queryable channel; immediately after creation, no subscribers exist and no events have been published. The event is ready for subscribers and producers to be wired up.
- Configure subscribers
Build the Apex trigger or Flow that subscribes to the event. For Apex, write a trigger on the Platform Event object that processes incoming events in bulk. For Flow, create a Record-Triggered Flow with the event as the trigger source. For external subscribers, configure the external system to subscribe via the Pub/Sub API or legacy streaming API. Test each subscriber by publishing a sample event from Event Studio's simulation tool and confirming the subscriber processes it correctly.
- Promote to production and monitor
Deploy the Platform Event definition and the subscriber code to production through the standard pipeline (Change Sets, SFDX, or DevOps Center). Activate the subscribers and confirm they receive events. Open Event Manager to monitor publish rates and subscriber lag during the first hours of production traffic. Set up alerts on any subscriber that falls behind. Schedule a weekly review of event metrics for the first month, then settle into the steady-state operating cadence.
The Platform Event type name and its constituent fields, designed before creation.
Required to create Platform Events and configure them in Event Studio.
At least one consumer to process the events. Events without subscribers are recorded but have no effect.
The org's edition determines available event publish and subscribe throughput; add-on allocation may be needed for high volume.
Documentation of the event purpose, fields, publishers, subscribers, and any operational considerations.
- Once a Platform Event is published to, changing its field shape is a versioning exercise. Design the event shape carefully before subscribers build against it.
- Publishing controls default to allowing any API-enabled user. Tighten the restrictions for high-impact events that should not be fired accidentally.
- Subscribers process events asynchronously. Synchronous behavior cannot be guaranteed, so design the integration with eventual-consistency assumptions.
- Replay is bounded by retention. Subscribers offline longer than the retention window lose events permanently.
- Test events fired from Event Studio behave identically to production events for subscribers. Be careful in sandbox to avoid triggering destructive downstream automation.
Trust & references
Straight from the source - Salesforce's reference material on Event Studio.
- Platform Events Developer GuideSalesforce Developer Docs
Hands-on resources to go deeper on Event Studio.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. How does Salesforce's multi-tenant model affect Event Studio?
Q2. Who can benefit from understanding Event Studio?
Q3. What does Event Studio represent in the Salesforce Platform?
Discussion
Loading discussion…