I'm looking for a way to bypass the Change Event trigger for some cases, for example, I have a batch that updates records and I want to bypass the Change Event trigger for that object to be triggered because it will hit the limit and it will be useless to run them at the same time, I know using static variable will not work because the trigger will be running on a different context, is there a way to disable it without using custom settings also?
1 Answer
As @identigral mentioned in the comment, it is possible to define a filter on channel member using subset of SOQL operators and field types.
You may introduce a custom checkbox Skip__c
and use a filter Skip__c = false
on channel member to skip records which have value true inside custom Skip__c checkbox. Then you just set the value of that checkbox to true if you want to skip the record or to false if you want to process that records from CDC.
To make things easier.
You don't have to update 100 places in your code.
Instead, you can implement a simple before update trigger with the following logic.
If Skip__c attribute was false but became true, do nothing. If Skip__c attribute was true, change to false.
This logic would automatically reset Skip__c field to false for UI updates, and any other updates. While when set by batch it will be preserved, since the previous value was false.
Alternatively, you may even disable a trigger when run from batch and simplify the trigger logic to always set to false.
-
It will not work in my case because I want the same record to be processed by the trigger when I update it in any place other than a specific batch, and using this variable will make it hard for us since we have to keep maintaining this field in different classes, I'm looking for a header that I can add to event so I can bypass the logic based on it. Sep 21 at 9:44
-
why not setting that field value in any other place to false but inside a batch to true? or have another field like last updated by batch? checkbox = true if last update by batch or false otherwise– PatlatusSep 21 at 10:33
-
Because maintaining this field will be very hard I have to visit around 100+ locations in code that were written a long time ago to add this flag, also another pain point we should inform our users that are doing updates using the UI to make sure to uncheck this field if it was checked by the batch, which you can imagine the amount of work needed. Sep 21 at 11:25
-
@user1391482 I have updated my answer with simple solution to maintain the field without updating 100+ locations in the code and without the need to inform users about doing any manual changes– PatlatusSep 21 at 13:09
-
Just to make sure the ChangeEvent trigger will be executed post-commit after the normal trigger has been executed, right? Sep 21 at 13:47