David Entremont: Increase Your Limits with the “Save Records Later” Action (Queueable Apex)
David Entremont has built a collection processor (a flow action designed to accept a collection of any type) that taps into Queueable Apex. If you use this to save your collection instead of Update Records or Create Records, it will be batched as a job to be run in the background. You can’t count on exactly when the save will complete, and this action returns a jobID that can be used to queue for status.
Why use this instead of standard data elements? Well, background jobs have more lenient limits. Here’s the best descriptions I’ve seen:
One of the main benefits of running asynchronous Apex is higher governor and execution limits. For example, the number of SOQL queries is doubled from 100 to 200 queries when using asynchronous calls. The total heap size and maximum CPU time are similarly larger for asynchronous calls.
Not only do you get higher limits with async, but also those governor limits are independent of the limits in the synchronous request that queued the async request initially. That’s a mouthful, but essentially, you have two separate Apex invocations, and more than double the processing capability. This comes in handy for instances when you want to do as much processing as you can in the current transaction but when you start to get close to governor limits, continue asynchronously.
https://trailhead.salesforce.com/content/learn/modules/asynchronous_apex/async_apex_introduction
You can learn more here:
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm
https://trailhead.salesforce.com/content/learn/modules/asynchronous_apex/async_apex_introduction
Installation
Install V0.1 Unmanaged (REQUIRES SPRING ’20)