Sometimes companies need to make bulk updates to all data so they can fill in object fields following a service call to an external platform that is communicating with their Salesforce org following an update to said object. So for this example we will say the object is Reward__c and they want to fill that new field on the Reward__c object called External_Image_Url__c. This field would be populated on an after update trigger call to the external system which would come back and update the Reward__c on its response with the proper External_Image_Url__c value. In this scenario this callout would be in queueable context to avoid governor limits. The company wants to update every Reward in their org with the new value. We will say 60,000 Reward__c records.

What reason is there that says creating a System administrator only async LWC to execute the updates on all 60k records, 50+ at a time, until all records have the desired field is not a good solution to assigning the field after hitting the already implemented service on the after update trigger of the Reward__c object?

In my opinion for this the solution would slowly assign all values to the Reward__c records without having to run a script manually over an over.

To prevent records from erroring over an over from being queried by the LWC you could have error flag set if that record came back from the service with an error the previous attempt that would need to be resolved before being attempted again by the service and even an error cause field for solutioning is needed.

This question is mostly about Best practice and why a script or a different update method is preferred over a LWC that wouldn't have to be closely monitored following initial execution provided the solution has already been tested in a lower environment with similar data.

1 Answer 1


It's kind of been done before, such as in HyperBatch (but uses Visualforce instead of LWC). There are a number of concerns with this approach, however.

First, remember that you're limited to how many concurrent callouts you can have to a given domain--across your entire org. Similarly, long running transactions may be cancelled if there are too many, so some careful design consideration is needed, and admins may need to coordinate between themselves if they plan on using it regularly.

Aside from the org-wide limits, though, client-side batching can be incredibly effective. With a proper design, you can potentially achieve 1,000+% faster updates than server-side processing alone. Just keep in mind that some configuration and hardware requirements might become necessary on the admin computers, such as turning off sleep/power saving modes, ensuring they have enough memory installed and available, and so on.

I have also used a similar design to, for example, scan every object key prefix to find any hidden sObject types that are in an org (e.g. because of features that are not enabled, etc). I've also used this trick to build an import wizard to upload records quickly from a CSV. It has a lot of practical uses that shouldn't be overlooked. As long as you remember to test things like concurrency, database contention, and so on, there's no reason why you shouldn't use this concept if it makes sense.

  • Boxcarring in LWC would be why the HyperBatch uses VisualForce removing. I would say that UI thread based batching of arbitrary data is a bad idea. Using problem domain segmentation and client-side parallel execution orchestration is, on the other hand, reasonable when that execution is simply shortening the real time processing for a UI-based action.
    – Phil W
    Dec 22, 2023 at 22:57
  • @PhilW "LWC" boxcar could not have been the reason. Visualforce remoting also has a boxcar effect. This is because RFC 2616 suggests a limit of max six connections at once to a domain, which most browsers follow. When HyperBatch (c. 2016) was made, Aura was barely on the scene (c. 2014), and Aura was dreadfully slow for a UI framework, so it would make sense that Daniel might have chosen Visualforce as the tool of choice. I probably would have, too at the time. LWC hyperbatching is blazing fast. It can be a good choice vs. batchable, which tends to have high latency.
    – sfdcfox
    Dec 22, 2023 at 23:29
  • @sfdcfox So essentially the only issue is Org limitation which would be an issue with either use-case since the same amount of callouts would need to be made to process that amount of data. With a timeout applied to the async callout to say wait 10-20 second between each execution of the batch script the concurrent callout issue would be avoided. You may have to execute the script a couple times assuming that it actually did trigger the "long running transaction" error but I believe the timeout would also avoid that issue. Are those the only "best practice" concerns?
    – NickZeus
    Dec 23, 2023 at 0:25
  • @NickZeus If this is a one-off, this is probably not faster from a dev perspective. Queueables queue up and work as resources allow, so you won't run into org limits that way. This might be a nice tool to have for other use cases, but for this specific task, maybe just use the Data Loader with Bulk API mode enabled. Bulk API is the best way to go when you need to hit 10k+ records quickly.
    – sfdcfox
    Dec 23, 2023 at 0:47
  • @sfdcfox I guess i did mess up on the question a bit. I was trying to portray that this couldn't be solved by data loader or import wizard. I understand the bulk api execution is great for single object updates but if the batch requires inputs from a related object then the data loader wont work.
    – NickZeus
    Dec 23, 2023 at 2:28

You must log in to answer this question.

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