Salesforce Platform Events offer a powerful mechanism for loosely coupled communication between different parts of your Salesforce org or even with external systems. However, many developers and admins fall into subtle traps that jeopardize performance, data integrity, or system limits. These missteps can cause serious headaches down the line, but fortunately, they are avoidable with the right knowledge and practices.
TLDR: Platform Events in Salesforce are incredibly useful, but they must be managed carefully to prevent scale, performance, and reliability issues. Common pitfalls include overusing events, missing error handling, ungoverned replay logic, and failing bulk operations. This guide identifies 7 key mistakes and how to fix each, with insights to safeguard your integration strategies. By proactively addressing these challenges, businesses can confidently scale their event-driven architecture.
1. Overusing Platform Events for Simple Automation
One of the most common errors made by developers is using Platform Events for tasks that don’t require asynchronous communication. If an operation can be handled synchronously or via other methods like flows or triggers, using Platform Events may actually overcomplicate the architecture.
- Why it’s a problem: Events add async complexity and may delay data consistency.
- Fix: Only use events when decoupling is essential. For localized or intra-transaction processes, favor process automation or Apex triggers.
2. Failing to Respect Order and Transaction Boundaries
Platform Events operate asynchronously and don’t guarantee the exact order of delivery across subscribers or systems. Developers assuming order invariance or transaction boundaries are preserved will be disappointed.
- Why it’s a problem: Data processed out of order can lead to inconsistency or duplicate logic execution.
- Fix: Design subscribers to be idempotent and not order-dependent. Use custom sequencing if absolute order is required.
3. Ignoring Replay ID Logic in Subscribers
The Replay ID is crucial when clients, such as external systems via CometD, subscribe to Platform Events. It lets them specify from where to continue receiving events. Mishandling this leads to lost or duplicate messages, especially after system restarts.
- Why it’s a problem: Lost data or repeated event replay leads to broken business logic or duplicate records.
- Fix: Implement stable storage for Replay IDs and ensure subscribers intelligently recover from disconnections or outages.
4. Neglecting Event Volume and Limit Constraints
Salesforce imposes strict limits on the number of events published and delivered. Failure to monitor volume or bulk-process events can lead to throttling, missed events, or governor limit errors.
- Why it’s a problem: High-frequency publishing can exceed daily limits or fail silently if unpublished.
- Fix: Monitor event usage via setup or Event Monitoring, and use
EventBus.publish()sparingly within bulkified Apex context.
5. Forgetting Durable vs High-Volume Event Subtypes
Salesforce offers different Platform Event types – Standard (durable) and High Volume (non-durable). Selecting the wrong type for your use case can result in reduced performance or data fidelity.
- Why it’s a problem: Durable events store for 72 hours, but limit publishing and are slower. High-volume events perform better but don’t persist.
- Fix: Choose based on frequency and reliability needs. Use High-Volume for frequent, non-critical messages; Durable for transactional integrity.
6. Non-Bulkified Event Subscribers
Subscribers, especially Apex Triggers on Platform Events, must be bulkified to ensure scalability. Writing subscribers that assume one-trigger-per-event causes record lock errors and slow processing under load.
- Why it’s a problem: Inefficient processing, hitting CPU timeouts or DML row limits.
- Fix: Always bulkify your subscriber logic. Use
for loopstructures and combine DML operations where possible.
7. No Dead Letter Queue or Error Recovery Strategy
Many mistakenly assume that once an event is published, Salesforce “takes care” of everything. In truth, subscriber failures result in dropped data unless specifically handled or monitored.
- Why it’s a problem: Business-critical events may fail silently without retry or alerting.
- Fix: Implement a logging mechanism inside subscribers. For external listeners, use retry queues or DLQs. Consider integrating with a monitoring tool.
Bonus Tips for Safe Platform Event Usage
- Normalize after-publish validations: Ensure event publishing succeeds before continuing workflows.
- Use Change Data Capture where suitable: For data change broadcasting, CDC may be more appropriate.
- Monitor Symbolically: Use tools like Event Monitoring and debug logs to review behavior during failures.
Conclusion
Platform Events unlock a modern event-driven idiom in Salesforce development—but they require thoughtful use. Avoiding these seven common pitfalls leads to more stable, scalable, and maintainable architectures and empowers developers to fully leverage Salesforce’s powerful integration framework.
Frequently Asked Questions (FAQ)
- Q: Are Platform Events stored in the database?
- A: No, Platform Events are stored in a temporary event bus and are generally not persisted unless configured as Durable Events. They are deleted automatically after 1–72 hours based on edition and volume.
- Q: Can Platform Events be rolled back?
- A: If published within the same Apex transaction scope, they can be rolled back on failure. Events published using
EventBus.publish()are part of the transaction context. - Q: What happens if a subscriber fails?
- A: If a subscribed Apex trigger fails, the transaction fails, but other subscribers might succeed. Without monitoring, you might not know it failed unless logs or alerts are set up.
- Q: How can I monitor event delivery?
- A: Use setup tools like Platform Event Usage and Event Monitoring. For external systems, maintain delivery logs and implement retry logic.
- Q: Can Platform Events trigger Process Builder or Flow?
- A: Yes, they can trigger Flows. However, due to async nature and potential volume, it’s advised to keep logic light and bulk-safe.