Platform Events can make Salesforce architectures faster, cleaner, and more scalable, but they can also lure teams into a dangerous trap: treating an event bus as a magic replacement for thoughtful integration design. When architects publish events without clear ownership, processing rules, retry plans, or monitoring, the result is often hidden data loss, runaway automation, and fragile business processes. A successful event-driven Salesforce implementation depends on discipline, not just enthusiasm.
TLDR: Platform Events are powerful, but they require careful design around event schema, publishing limits, transaction behavior, replay handling, monitoring, and subscriber logic. The most common failures happen when teams assume events are guaranteed, immediate, or suitable for every use case. By recognizing the seven fatal mistakes below and applying practical fixes, Salesforce teams can avoid brittle integrations and build reliable event-driven systems.
The Platform Event Trap
In Salesforce, Platform Events allow applications to publish and subscribe to event messages through the event bus. They are especially useful for integrations, decoupled automation, near real-time notifications, and asynchronous processing. However, their convenience can hide important architectural trade-offs. A team may begin with one simple event and quickly build a tangled web of publishers, subscribers, flows, Apex triggers, external middleware, and downstream systems.
The “Platform Event trap” occurs when organizations treat events as a universal solution instead of a specialized pattern. The event bus becomes a dumping ground for every update, every status change, and every integration request. Soon, no one knows which system owns the truth, which subscribers are critical, or what happens when a message is missed.
1. Mistake: Using Platform Events for Everything
The first fatal mistake is assuming Platform Events should replace all synchronous APIs, batch jobs, outbound messages, change data capture, and scheduled integrations. Platform Events are excellent for announcing that something happened, but they are not always the best tool for data replication, large volume migration, or request response operations.
For example, if an external system needs an immediate response confirming that a record was updated, a synchronous API may be more appropriate. If a data warehouse needs every field change across large objects, Change Data Capture may be better. If millions of historical records need to move, bulk APIs and ETL processes are usually safer.
Fix: Teams should define a clear decision framework before adopting events. Platform Events are most suitable when:
- A business fact needs to be broadcast to multiple systems.
- Processes can tolerate asynchronous behavior.
- The publisher should not need to know every subscriber.
- The event represents a meaningful state change, not just a technical update.
Architects should document when Platform Events are allowed, when they are discouraged, and which alternatives should be considered.
2. Mistake: Designing Weak Event Schemas
A weak schema turns a Platform Event into a confusing message that subscribers cannot trust. Some teams create vague fields such as Status, Payload, or Message without defining what values they contain. Others include too much data, effectively turning the event into a full record snapshot. Both approaches create long-term problems.
An event should describe a business occurrence clearly. A schema such as Order_Submitted__e with fields for OrderId, CustomerId, SubmittedDate, and SubmissionSource is easier to understand than a generic System_Message__e with a large text payload.
Fix: A strong event schema should be specific, stable, and business-oriented. Teams should follow these practices:
- Name events after business facts, such as Invoice_Paid__e or Case_Escalated__e.
- Include identifiers so subscribers can retrieve additional data if needed.
- Avoid unnecessary fields that expose internal implementation details.
- Version schemas carefully when changes may break subscribers.
A Platform Event is a contract. Once external systems depend on it, careless changes can cause serious failures.
3. Mistake: Ignoring Publish Behavior and Transaction Boundaries
Many Salesforce teams misunderstand when events are actually published. Platform Events can be configured to publish immediately or after commit, depending on the use case and publishing method. This distinction is critical. If an event is published before the transaction successfully commits, subscribers may act on data that later rolls back. If it is published after commit, subscribers only receive the event once the database transaction succeeds.
This mistake often appears in Apex or Flow automation. A process publishes an event, then a later validation rule or exception causes the main transaction to fail. External subscribers may still believe the business action happened, even though Salesforce rolled it back.
Fix: Architects should intentionally choose publish behavior and document it. For most business events that represent confirmed state changes, publishing after commit is safer. Developers should also test failure scenarios, not just happy paths. A good test confirms what happens when validation errors, governor limits, or exceptions occur after the event publication step.
4. Mistake: Forgetting About Limits and Volume
Platform Events are scalable, but they are not unlimited. Salesforce enforces limits around publishing, delivery, retention, subscriptions, and event allocations. A design that works in a sandbox with a few dozen records may collapse during a production campaign, data load, or seasonal spike.
Volume problems become worse when automation publishes events inside loops or when multiple subscribers perform expensive processing for every message. A single record update can trigger flows, Apex triggers, Process Builder remnants, and integrations that all publish additional events. This creates an event storm.
Image not found in postmeta
Fix: Teams should estimate event volume before deployment. They should identify peak scenarios, not just average usage. Proper safeguards include:
- Bulkifying Apex publishers and subscribers.
- Avoiding event publication inside unnecessary loops.
- Using filters or routing logic so subscribers process only relevant events.
- Monitoring daily event usage and delivery metrics.
- Planning license and allocation needs before production rollout.
High-volume event architecture should be tested with realistic loads. Performance assumptions are not a substitute for measurement.
5. Mistake: Building Subscribers That Are Not Idempotent
In event-driven systems, subscribers must be prepared to process the same event more than once. Duplicate delivery, retries, replay, or external reconnection behavior can cause repeated processing. If a subscriber creates a payment, opens a case, or sends a customer email every time it receives an event, duplicate messages can create costly damage.
This issue is especially dangerous because it may not appear during initial testing. Everything looks fine until a connection drops, a middleware service retries, or an administrator replays events from a previous replay ID.
Fix: Every critical subscriber should be idempotent, meaning repeated processing of the same event produces the same result as processing it once. Common techniques include:
- Storing processed event IDs or business correlation IDs.
- Checking whether the target record or action already exists before creating it.
- Using external IDs and upsert operations instead of blind inserts.
- Designing downstream systems to recognize duplicates safely.
Idempotency is not optional for serious event-driven architecture. It is one of the core protections against accidental duplication.
6. Mistake: Neglecting Replay, Retention, and Recovery
Platform Events are retained for a limited time, depending on the event type and Salesforce capabilities available in the org. Subscribers use replay IDs to resume from a point in the event stream. Problems arise when teams do not store replay IDs, do not understand retention windows, or assume old events can always be recovered.
If an external integration is offline longer than the retention period, missed events may no longer be available. Without a recovery process, the external system becomes permanently out of sync. This is one of the most common traps: the team believes the event stream is a durable queue, but it is not a permanent archive.
Fix: Each subscriber should have a recovery strategy. That strategy may include:
- Persisting replay IDs after successful processing.
- Alerting when a subscriber disconnects or falls behind.
- Creating reconciliation jobs to compare Salesforce data with downstream systems.
- Using a durable middleware queue when longer retention is required.
- Defining manual recovery procedures for missed events.
Organizations should assume that subscribers will eventually disconnect. A resilient design plans for that moment in advance.
7. Mistake: Treating Monitoring as an Afterthought
The final fatal mistake is launching Platform Events without operational visibility. Unlike a failed button click or a visible validation error, event failures can be quiet. A publisher may succeed while a subscriber fails. A middleware service may stop consuming. A flow subscriber may hit a limit. An external endpoint may reject messages. Business users may notice only days later, when invoices are missing or customer records are outdated.
Image not found in postmeta
Fix: Monitoring should be part of the original design. Teams should track event publication rates, subscriber health, processing errors, replay position, and downstream acknowledgments. For internal processing, Apex error handling and logging should capture failed event trigger runs. For external integrations, middleware should expose dashboards, alerts, and dead letter handling where possible.
Effective monitoring answers three questions:
- Was the event published?
- Was the event received by the intended subscriber?
- Was the business action completed successfully?
If the organization cannot answer all three, the event architecture is not production-ready.
Other Best Practices for Safe Platform Event Design
Beyond avoiding the seven fatal mistakes, mature Salesforce teams usually adopt a few additional habits. They maintain an event catalog that lists every Platform Event, its publisher, its subscribers, its purpose, and its owner. They use naming conventions that separate business events from technical events. They also review event dependencies during release planning, because changing one event may affect multiple systems.
Security must also be considered. Platform Event permissions determine who can publish and subscribe. Sensitive data should not be placed in events casually, especially when external systems consume them. If subscribers only need a record ID, the event should not include private customer details.
Finally, teams should avoid building hidden chains of events unless there is a clear reason. When one event triggers another, which triggers another, debugging becomes difficult. A simple, well-documented event flow is usually better than an impressive but mysterious automation web.
Conclusion
Platform Events can help Salesforce teams build flexible, decoupled, and scalable solutions, but only when they are treated as architectural contracts rather than casual notifications. The biggest risks come from unclear schemas, poor transaction awareness, uncontrolled volume, non-idempotent subscribers, weak recovery plans, and missing monitoring.
An organization that avoids these traps gains the real value of event-driven architecture: systems that communicate efficiently without becoming tightly bound to one another. The best Salesforce architects do not ask whether Platform Events can be used. They ask whether events are the right fit, what can go wrong, and how the design will recover when it does.
FAQ
What is a Platform Event in Salesforce?
A Platform Event is a special Salesforce object used to publish and subscribe to event messages. It allows Salesforce and external systems to communicate asynchronously through the Salesforce event bus.
Are Platform Events guaranteed to be delivered?
Platform Events are designed for reliable event delivery within Salesforce limits and retention rules, but teams should not treat them as a permanent message archive. Subscribers need replay handling, monitoring, and recovery processes.
When should a team avoid Platform Events?
A team should avoid Platform Events when a process requires an immediate response, permanent message storage, bulk historical migration, or simple scheduled synchronization. In those cases, APIs, batch jobs, Change Data Capture, or middleware queues may be better.
What does idempotent subscriber mean?
An idempotent subscriber can receive the same event more than once without causing duplicate or incorrect outcomes. For example, it checks whether an action has already been completed before performing it again.
How can Salesforce teams monitor Platform Events?
They can monitor publication volume, subscriber errors, middleware logs, replay positions, and downstream completion status. Strong monitoring should show not only that an event was sent, but also that the intended business action finished successfully.
Should Platform Events include all record data?
Usually not. A Platform Event should include only the data subscribers need to understand and process the event. In many cases, record IDs and key context fields are enough, while subscribers can query additional data when necessary.
