In the last post, we looked at implementing a custom version of the Salesforce vote object to avoid potential record locking issues for custom objects. We did this with a child helper object that contained the data, which was then rolled up onto the parent object. But what if we need more complex logic than just a tally of the data? What if the data, once used, was no longer necessary to store? Using a helper object gets around the record locking issue, and also gives us the ability to add custom trigger logic that runs every time one is inserted into the database.
An after insert trigger for the helper object can be used to process the actual intended record updates, rather than relying on a rollup field. First, all helper objects in the Trigger.new list are mapped to their parent records, while the parent records themselves are pulled down from the database. Each parent record is then updated according to the custom logic desired, using all of their child helper objects in this transaction. Finally, a single DML call is made to update all of the parent records that were modified during this transaction.
Since we are using a trigger on the helper object, we also have the ability to tie in any other Salesforce objects or processes. If the customer is logged in, we have access to all related Salesforce records such as their account and contact information. Updates to these records can be made, or data from the records can be used to conditionally update the parent record of the helper object. There are very little limitations on what kind of custom functionality can be built out this way.
For a system where it is unnecessary for the the helper object data to persist after the calculations are made to the parent, we can make the helper object self-deleting. What this means is that after all the custom logic processing is completed in the after insert trigger, we add logic that deletes all helper objects that were part of this transaction. We do this to ensure we are not storing large amounts of custom object data when we do not need to, since Salesforce storage does have limits.
Expanding upon the basic helper object allows for the implementation of complex functionality for customer input within a Salesforce community.