Platform Events have revolutionized Salesforce teams’ approach to real-time data and system integration. They enable various components of an org to communicate with one another instantly, without slowing everything down.
However, many admins and developers end up making common mistakes that could be the platform event trap, a collection of commonplace errors that can silently destroy otherwise sound systems.
Unfortunately, these errors can result in outages, data loss or confusing bugs that only manifest with real users. This guide takes you through the reason for the trap, the indicators to look out for and easy methods to stay clear of the trap.
What is a Platform Event Trap?
A platform event trap is not a particular bug. It’s a series of design errors that sum up over time. Their problems stem from a lack of understanding, they anticipate that Platform Events will behave as they imagine, with predictable behavior and real-time response; but in reality, Platform Events are designed to be run in the background, where they don’t always respond in real time nor necessarily in the order in which they are triggered.
The difficult aspect is these problems seldom manifest early. A setup may pass all the tests in a sandbox, but fail when deployed and used in a real environment with real traffic. The platform event trap typically makes it in between “it works in testing” and “it works in production.
Common Errors That Get You Into a Platform Event Trap
Using Platform Events for Synchronous Flows
Platform Events are designed to be asynchronous. This means that if you publish one you don’t receive an immediate reply. A common user error is using them in contexts where the user thinks he/she will get instant feedback, such as updating a screen after an action. Delays or blank screens show when it takes a few seconds to process the event, and the experience is broken for the user.
There is a simple solution to this: Use Platform Events to perform background work that doesn’t require it to occur immediately. You are not allowed to use Apex or Lightning Message Service for real-time feedback in the interface.
Failure to Provide Event Ordering and Delivery Guarantees
One fun thing that many teams don’t realize until they have an issue is that Salesforce doesn’t guarantee that events will be received in the order they are sent. Your logic on implementing Event A before Event B is on shaky ground.
To prevent that, construct your event consumers to not rely on the ordering. If you add sequence numbers, timestamps or logic that allows you to deal with events coming in out-of-order, you will save yourself from mismatching data later on.
Unenforcing Volume Limits Or Governor Restrictions
Each Salesforce organization is restricted to publishing and processing a certain number of events per day and has a limit on the number of subscribers that can listen concurrently. Events aren’t always throttled or dropped when they get a high load of traffic, so teams that do not take these limits into consideration may get surprised.
Prior to scaling, review your limits in your organisation for events and plan your integration to fit in within the limits and allow for expansion.
Read Also: Thetechyx.com: Complete Guide, Features & What to Expect
Testing Only in Limited Environments
The limits for Developer Edition orgs and sandboxes are much more limited than production. A workflow that performs well on testing could break apart in production once it reaches the scale of a few hundred events per day, but it could reach a hundred of thousands of events per day.
This mismatch is one of the most frequent causes of the implementations to fail immediately after they are launched, even though, prior to launch, they seemed to be all set up.
What you need to do is test at volumes that will mimic real production traffic and not enough to make sure that the basic logic is correct.
Inadequate Security and Access Configuration
It is easy to get events flowing and neglect to secure who should be able to subscribe to and publish events. Loose permissions can be a result of unauthorized access, unexpected event triggers, or data exposure. Proper sharing rules and access control implementations at the outset maintain a secure and functional event architecture.
The First Signs of a Platform Event Trap
It can be detected even if there is only a partial power loss. Look out for these signs:
Missed or lost events. The once-fast processing times are beginning to slow down or just stall.Previously rapid processing times have begun to lag or fail without notifications.
Multiple or conflicting records. Data does not match due to duplicate and/or out-of-order processing.
Slow UI behaviours. Stale or missing information will begin to appear on screens that are expecting real-time information.
Errors that are only seen when data is accessed. Errors which can only be observed when loading data. Light testing, no problems, real user volume, break.
If you are able to identify these as early as possible, you have the opportunity to correct the design before it is a serious production problem.
Best Practices For Avoiding the Platform Event Trap
Once you understand where the traps are, avoiding the platform event trap is a matter of a few basic ‘hacks’:
Do not block Platform Events with sync. Do not sync Platform Events. Use them as background, for decoupled processes, not something that requires immediate response.
Make use of the appropriate tools to provide feedback in real-time. For instant updates to the UI, use Apex or
Lightning Message Service
Plan for out of sequence and repeat events. Consumers should be idempotent, otherwise it will cause problems when processing the same event multiple times.
Track delivery and arrange for re-deliveries. Monitor and track failed or stalled events and provide for automatic retries or handling of errors.
Test for load before putting it online. Simulate a few or a huge number of test events, NOT production volume.
Apply least-privilege access. Don’t publish and subscribe to permissions that are not needed by the users and systems.
The following steps will not take much time, but will add a lot to the success of your event-driven setup once you start getting real visitors.
Creating Event-Driven, Scalable Architecture on Salesforce
It’s not just to get Platform Events working for the launch day, it’s about creating something that works for your growing organisation. That involves more than just the initial rollout: What will this do when there are triple the number of events in a year? What if there is a down failure of a downstream system for an hour?
These life cycles should be planned for, rather than being patched and fixed after they happen, and that is where the difference between a stable and a patching event-driven architecture lies.
Instead of thinking of event design as just a setup once, you need to think of it as an ongoing process as you add more usage and integrations.
Final Word
This is not due to a single big mistake, typically, a series of small, easily preventable errors, building up over time. The most common reason is misusing the asynchronous events, ignoring delivery guarantees, skipping load testing and loose security. The bad news is they all can be prevented with a little forethought.
If you’re on Platform Events today, or you’re considering implementing Platform Events, it’s important to reflect on your setup to make sure you’re avoiding these common traps to ensure you’re on the right path for scaling further down the road. Taking a little extra care now can save you a LOT of headaches later.
FAQs
1.What does a “Platform Event Trap” do in Salesforce?
It’s a series of unnecessary errors in use of Platform Events, such as taking all Platform Events for granted are synchronous or being unaware of delivery limits, that can lead to outages and data loss.
2.What makes platform event traps go untrapped until production?
The volume limits and number of concurrent subscribers for Sandbox and Developer Edition environments are much lower than in a production environment.
3.Can Platform Events guarantee the order of delivery?
No, Salesforce will not guarantee that Platform Events will be received in any specific order. Extra logic is required for systems that require strict ordering.
4.What’s the best way to not use Platform Events wrong?
Only use Platform Events asynchronously and in an uncoupled way. If you need to provide UI feedback in real-time, use the Apex or Lightning Message Service.
5.What could present the greatest risk in platform events?
The greatest dangers are lost data without realizing it, data duplication, and service downtime, which are only found after implementing the operation into the live environment with real production traffic.
Read More: Zoechip: A Complete Look at the Free Streaming Site Everyone Is Talking About
