Apex Code Development You need to sign in to do that
Don't have an account?
Joseph Bleau One trigger per object is commonly espoused as best-practice, but is that so for Event triggers?
According to the documentation it is considered best practice to maintain multiple triggers even for Events:
But it seems to me less obvious that this is as important for events as it is for objects. Where an Object trigger is directly tied back to a singular record in Salesforce concurrency issues are obvious. Events on the other hand don't necessarily have to be underpinned by any specific record, nor do they even need to be contextually related to existing records at all.
It seems to me sort of antithetical to the notion of a pub/sub to captiulate at the point of subscription and re-couple subscriber logic in one place in the Org. Wouldn't it be better if all interested consumers implemented their own event listeners? There would not be a single point of failure and conflict which is a common ailment of Object triggers (granted, with patterns that help).
I'd like to see this footnote in the documentation expanded on a bit more. It doesn't seem obvious to me that this advice is as applicable as it was and I'd be curious to hear others thoughts as well.
... However, having multiple triggers on the same object isn’t a best practice because we can't guarantee the order of execution, so we recommend that you add only one trigger per object.
https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_subscribe_batch_resume.htm
https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_subscribe_batch_resume.htm
But it seems to me less obvious that this is as important for events as it is for objects. Where an Object trigger is directly tied back to a singular record in Salesforce concurrency issues are obvious. Events on the other hand don't necessarily have to be underpinned by any specific record, nor do they even need to be contextually related to existing records at all.
It seems to me sort of antithetical to the notion of a pub/sub to captiulate at the point of subscription and re-couple subscriber logic in one place in the Org. Wouldn't it be better if all interested consumers implemented their own event listeners? There would not be a single point of failure and conflict which is a common ailment of Object triggers (granted, with patterns that help).
I'd like to see this footnote in the documentation expanded on a bit more. It doesn't seem obvious to me that this advice is as applicable as it was and I'd be curious to hear others thoughts as well.
Joseph BleauSorry I had a typo in my first sentence. It should read: It is considered best practice to maintain A SINGLE trigger, even for Events.