14

I've been playing around with change event triggers to get an understanding of them and I noticed that if my objects have fields with default values, those fields are being included in the update change event. These include all checkboxes and other fields such as numeric fields that have a specified default value.

For example, I enabled change data capture on opportunity and then wrote a simple trigger to see what is coming into the trigger.

trigger OpportunityChangeEventTrigger on OpportunityChangeEvent (after insert) {
    for (OpportunityChangeEvent event : Trigger.New) {
        System.debug(JSON.serializePretty(event));
    }
}

If I look at the debug log for the automated process user, I see more fields than I actually changed on an opportunity update.

How can I tell which fields were actually changed using a change event trigger?

6

Answer from John Brock at Salesforce:

This is not expected behavior and we have a bug logged. If you have a case filed, please let me know so I can get it linked up to the right ticket. The expected behavior is that unchanged fields shouldn't have a value which could be misinterpreted as a change -- or we need to provide information for you to make this determination. Nulled fields should be identified using the nulledFields array in the ChangeEventHeader. In Winter [20] or Spring [20], we will likely replace nulledFields with changedFields to make this distinction of change field values more explicit.

Known Issue: https://success.salesforce.com/issues_view?id=a1p3A0000003cyRQAQ

0

Daniel, have you tried to use the event's ChangeEventHeader information? It can be: CREATE, UPDATE, DELETE, UNDELETE

trigger OpportunityChangeEVTTrigger on OpportunityChangeEvent (after insert) {
for (OpportunityChangeEvent event : Trigger.New) {
      EventBus.ChangeEventHeader header = event.ChangeEventHeader;

      System.Debug('Change header: ' + header.changetype);
      System.Debug('**************************');

    if (header.changetype == 'UPDATE' ) {               
       System.debug(JSON.serializePretty(event)); 
    }

  }
}

And, the Test Class, serializing the data only when there's an Update, which now, besides default properties, is showing the changed fields only (a custom field named Temperature__c):

@isTest 
public class OpportunityChangeEVTTriggerTest {

@isTest 
public static void testUpdateChangeEventTrigger() {
    // Enable all Change Data Capture entities for notifications.
    Test.enableChangeDataCapture();

    Opportunity oppTest = new Opportunity();
    oppTest.name = 'Test';
    oppTest.StageName = 'Closed Won';
    oppTest.CloseDate = date.today();
    oppTest.Type = 'New Customers';

    insert oppTest;

    // Deliver test change events
    Test.getEventBus().deliver();

    oppTest.Temperature__c = 'Hot';
    update oppTest;

    // Deliver test change events
    Test.getEventBus().deliver();

}

The detail in the log:

"Temperature__c" : "Hot",
"HasOpportunityLineItem" : false,
"IsExcludedFromTerritory2Filter" : false,
"IsWon" : false,
"ReplayId" : "2",

Please let us know if that helps!

  • It is an Update event. The problem is that it is giving me all the fields that have a default value assigned even if they aren't changed. – Daniel Hoechst Jul 5 at 21:14
  • 2
    Yes - that's the whole point of the question. – Daniel Hoechst Jul 5 at 21:25
  • 1
    @toadgeek In my experience the logging can be very deceptive if you're running unit tests to try it out. – David Reed Jul 5 at 22:21
  • 2
    But, do you have any fields with a default value?Try adding a custom checkbox and a numeric field with a default value of 0 on the object. In my org they are always being included. – Daniel Hoechst Jul 5 at 23:24
  • 2
    This is not expected behavior and we have a bug logged. If you have a case filed, please let me know so I can get it linked up to the right ticket. The expected behavior is that unchanged fields shouldn't have a value which could be misinterpreted as a change -- or we need to provide information for you to make this determination. Nulled fields should be identified using the nulledFields array in the ChangeEventHeader. In Winter or Spring, we will likely replace nulledFields with changedFields to make this distinction of change field values more explicit. – John Brock Jul 9 at 5:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.