function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Custom Object "Log" for Recording changes to Master and Detail object records

We have a need to track changes (creates, updates, deletes) to a parent record and all related records. Field History works somewhat. We need to track record deletes though, so obviously field history tracking won't accomplish that requirement.


My theory is that I could create a custom object called "Log" and use Apex to populate the log with records that store information about creates, updates and deletes to any records related to the parent record with date/time stamps and user information. These log records could then be used in reports. 

Does anyone know of a solution or have any guidance?


I strongly recommend you avoid this approach. Assuming a user performs a modest 50 tracked modifications (including deletes) per day, in an organization of 10 users, an organization could eat through 1 GB of storage in just under four years without ever creating a single new record, and even deletions would contribute to the storage problem, thus ultimately creating a huge (data storage-wise) entity. Not to mention that high traffic records would be clogged with useless rows of data over and again. The only way I would see a custom-built tracker system working would be with the use of some auto-archiver or a maximum log-per-record limit.


The storage, reporting, and display list concerns aside, you can certainly do this with Apex Code. It would be a trigger on the child object that would track changes back to the parent record. I believe an optimal approach would include a Lookup relationship to the tracked object for reporting and click-through purposes. It can't be a master-detail, because you can't have custom master-detail-subdetail records (yet), and because if you could, it would not be able to track deletes-- the record being tracked would drag its history to the recycle bin with it.


A "better" idea might be to use a LTA (that's Long Text Area) with read-only properties (that would be enforced via triggers) and simply accumulate notes into this field, or perhaps even use the Notes & Attachments section. I know it's kind of a "old-fashioned" solution, but if you're going to be generating a ton of traffic, this is a far better solution. You could even make it a RTA (Rich Text Area) so you can use HTML and such to make it look pretty, and automatically archive notes as the field reaches its maximum size (into Notes, or a History object that would use far less storage than a one-record-per-change system).


You may want to research how much usage you anticipate on these records. It may be that a one-record-per-change system will work for you, with a periodic archive period of 180 or 360 days. Archived records could be stored offline for viewing older details, or stored in an alternate system that integrates with and isn't as expensive with data storage.