Feature idea: Support automatic cleanup of `AsyncResult__c` records

[tzinm]

While browsing the web, I came across your blog, which features some interesting content about Salesforce development. After reading a few posts, I discovered your GitHub organization and found several useful frameworks. One of my favorites is SOQL Lib and the approach you take to handling selector classes.

Small Selector Classes - The selector class should be small and contains ONLY query base configuration (fields, sharing settings) and very generic methods (byId, byRecordType). Why?

• Huge classes are hard to manage.
• A lot of merge conflicts.
• Problems with methods naming.

Now that you’ve released a new framework (I learned about it through your latest blog post), I took a look and wanted to share an idea to potentially extend it.

What’s the idea?

The framework stores execution results in the AsyncResult__c object, which is very handy. However, I see a potential risk in the long run: record accumulation in this table if not properly managed.

To address this, I’m suggesting the introduction of an automatic cleanup mechanism for old AsyncResult__c records. This feature could be configurable via the existing QueueableJobSettings__mdt Custom Metadata Type, using fields such as:

• A AutoCleanUpRecords__c checkbox field to enable or disable the cleanup.
• A CleanUpFrequency__c picklist field with values like: Daily, Weekly, Monthly, Yearly.

The existing metadata record could act as the global default configuration, so that jobs without a dedicated configuration would inherit this fallback behavior.

As for the actual cleanup process, a scheduled job (e.g., AutoAsyncResultCleanupScheduler) could run daily and:

• Read all active job configurations.
• Determine which records are eligible for deletion based on the configured frequency.
• Launch one or more async jobs to delete the identified records.

This would help ensure the framework remains sustainable over time by avoiding uncontrolled data growth. , while keeping the implementation transparent and maintainable for teams adopting the framework.

Let me know what you think!

[Mateusz7410]

Hello @tzinm !
Thank you for the message!

I totally agree with you; that was one of my post-MVP enhancements to do. Not sure when I will implement it, but it should be quite an easy thing to do.

Once added to the roadmap, will update you.

[tzinm]

Do you already have in mind what kind of approach you'd like to take for this enhancement?

One possible idea could be to provide a button in the list view of the AsyncResult__c object (something like "Enable Automatic Cleanup") that would allow admins to enable the job responsible for automatically removing records from this object.

• In terms of security, I assume no additional logic would be required. The expectation would be that the team implementing the framework handles permissions so that only platform administrators have access to the object, its list views, and available buttons.
• Regarding the button's behavior, it could work as follows:
  • If a cleanup process is already running when the button is clicked, the user would see a notification informing them that the job is currently in progress.
  • If no job is running, the cleanup job would be triggered. Since this would be used by admin users, would it make sense to also display the Job ID once it's launched?

Additionally, it might be useful to leverage the existing AsyncResult__c object to store the results of the job itself.

[Mateusz7410]

I was not thinking about that, but that would be something similar to what you have described.
Quick action to show the LWC component, which will show either the link to the job (if already scheduled) or the option to select the interval, and schedule the job (if not scheduled.
So the button would be called something like "Retention Settings".