2

For a few reasons**, I'd like to build the following. Upon updating CustomObj1 (usually via Edit->Save),

  • Take a 'snapshot' of that object, recording all field values.
  • Find out which field values changed in CustomObj1 before Update
  • Insert a record into another c-object, CustomObj2, which is a near exact-replica of the original custom object, CustomObj1
  • Add those values as content in a large Text box in CustomObj2, perhaps broken by line breaks and/or Bullet points (for summary details about the record Update)
  • Insert CustomObj2, with a foreign-key reference to CustomObj1 (one-to-many relationship, CustomObj1 to CustomObj2)

And a few questions/Concerns:

  • What is the best way to identify changed field values? Perhaps with a for each?
  • Is this going to be a nightmare in terms of data size? CustomObj1 currently has about 30 custom fields, and less than 5,000 records. These are updated somewhat frequently, though, at about 1-3 times per month, each.

** My reasons, in case you think I'm crazy:

  • Activity History for objects only supports about 20 fields, I have more than that at this point
  • Full object snapshots could be really valuable down the road
  • Looking to get more trigger experience regarding data manipulation

2 Answers 2

2

This would be excellent trigger practice. Using dynamic apex you can get a list of all the fields for an object, which you can then iterate over to see if anything has changed. If you do, make a snapshot.

Another approach would be to build a gigantic string of all the fields in the object (excluding lastModifiedDate, lastModifiedBy, and sysmodstamp, which get updated even if no actual change has occured). Then create a hash from the resulting string, compare this to the last hash you have for the object and if it doesn't match it something has changed and you'll need a snapshot.

As for which fields to check you can use the following syntax which returns the API names for all fields on the object.

Schema.SObjectType.YourObject__c.fields.getMap().keySet()

Another option, if you don't care about every field would be to make a field set and iterate over that instead.

1
  • Thanks, Ralph. If you have any other code samples that would be helpful, but I think I can get the majority of this done with your advice
    – CDD
    Nov 30, 2013 at 21:18
2

I suggest instead of exact-replica of the original custom object you should save only the changes of each record inside CustomObj2 records so that no need to iterate over the history records with each field check. On edit of the record find the fields updated. and write just that filds inside the custom object2. In this case the history can be maintained with just two fields the parent id and the change ie past and present values of only those fields which are updated. This will reduce the DB size and increase query speed.

2
  • Just to clarify, would you recommend keeping the metadata lined up for the two objects, but only populate the changed field, resulting in records that contain mostly blank fields? Or just do a pivot-table style, where I keep the Field_Name__c and Field_Name__c.OldValue and Field_Name__c.NewValue?
    – CDD
    Nov 29, 2013 at 19:17
  • Create a record in CustomObj2 when atleast one field changed and on the changed field has to be recorded in Field_Name__c and Field_Name__c.OldValue and Field_Name__c.NewValue format Dec 1, 2013 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .