Dataverse bulk updates: choose the right operation

Key insights

• ExecuteMultiple groups individual requests; it is not equivalent to the set-oriented UpdateMultiple operation.
• UpdateMultiple is intended for many records in one table, when the table and scenario support it.
• Synchronous plug-ins and other server-side logic can remain a significant part of bulk-update processing time.
• Oversized batches and excessive concurrency can hurt performance or trigger Dataverse service-protection limits.
• Measure throughput, duration, errors and throttling with the actual table type and workload.

Microsoft Dataverse bulk updates do not guarantee faster processing: the operation, payload, server-side logic and concurrency all affect elapsed time. This matters to Dataverse developers, consultants and Power Automate makers who update many records and need to choose an approach that fits their workload. Softchief Learn’s post raises the performance question and names UpdateMultiple, ExecuteMultiple, plug-in overhead and a 10,000-account scenario as topics.

What it does

Dataverse offers several ways to update records, and they do not all process work in the same way. An individual Web API update sends one request per record. ExecuteMultiple groups individual requests in one batch, which can reduce network overhead, but the updates inside remain individual operations.

UpdateMultiple is a purpose-built bulk operation for updating multiple records of the same table. Microsoft guidance summarized in the research notes says bulk messages can be more efficient than a batch of individual requests because the plug-in pipeline can run for the set rather than repeating the full operation pattern for every row. The improvement is not automatic: the table and scenario must support the operation, and other work performed during each update still matters.

Other operations serve different needs. UpsertMultiple is suited to cases where records may need either creation or updating, while ExecuteMultiple can fit batches of varied individual operations. Batch requests and change sets can be appropriate when work spans tables or needs transactional behavior. The best choice depends on the job, not simply on whether a method is called “bulk.”

Who it is for and what you need

This is relevant to Dataverse and Dynamics 365 developers, Power Platform consultants, architects and makers building data imports or synchronization jobs. The source description also identifies Power Automate developers as an audience and mentions an example involving 10,000 accounts. It does not provide the example’s configuration or measured results.

The supplied material does not state a required license, plan, region or rollout stage. It also does not establish that UpdateMultiple is supported for every table. Check support for the target table and operation before designing around a bulk message; the performance notes specifically advise using dedicated bulk APIs when supported by the table and scenario.

Test with the production-relevant table type, schema, data volume and server-side logic. Standard and elastic tables can have different performance characteristics, so results from one type should not be treated as a prediction for another. The notes do not identify a specific Dataverse environment or provide a universal batch-size setting.

How it works

Start by identifying whether the workload updates one table or combines different operations. For a high-volume update to one supported table, evaluate UpdateMultiple. For varied individual operations, evaluate ExecuteMultiple; for multiple tables or transactional requirements, consider batch requests or change sets. If records may need to be created as well as updated, evaluate UpsertMultiple.

1. Choose the operation that matches the workload and confirm that the table supports it.
2. Send only the columns that need to change rather than retrieving and resubmitting full records.
3. Test several batch sizes. The research notes describe 100 to 1,000 records as a common range for standard-table guidance and about 100 for elastic tables, but stress that payload and workload affect the result.
4. Measure records per second, request duration, failures and throttling. Include plug-in execution time where available.
5. Increase parallelism gradually. If a Web API response returns HTTP 429 with a Retry-After value, honor the delay rather than retrying immediately.

Server-side work can outweigh the benefit of reducing requests. Synchronous plug-ins, workflows, business rules, calculated or rollup fields, auditing and related-record updates may all contribute to processing time, according to the research notes. Bulk processing does not make that logic disappear. Any decision to minimize or bypass custom logic needs careful assessment because it may affect validation, related records, auditing, security assumptions or integrations.

Limitations and open questions

A bulk request can take longer in a particular test even if it reduces round trips. Payload construction, serialization, server processing and response handling all contribute to elapsed time, and fixed overhead can matter more for smaller jobs. If server-side logic dominates, changing the request format alone may not solve the bottleneck.

Very large batches can increase processing time and timeout risk. Too many concurrent requests can also trigger service-protection limits; the notes describe those limits as considering request volume, cumulative execution time and concurrent requests. Avoid assuming that the largest batch or highest parallelism is fastest. Tune both against measured results, and make retry handling respect the service’s Retry-After response.

The available post description does not supply a transcript, benchmark figures, a specific implementation, or a before-and-after comparison. It raises the question of why individual updates might sometimes beat a bulk approach, but does not establish that result for every workload. The practical takeaway is to compare the supported operations under the same table, data, logic and environment conditions.

Sources

• Softchief Learn’s Dataverse bulk-update post

Frequently asked questions

Is UpdateMultiple always faster than ExecuteMultiple in Dataverse?

No. UpdateMultiple is designed for bulk updates to one table and can be more efficient, but support, server-side logic, payload size and workload affect the result. Measure both approaches where applicable.

What batch size should I use for Dataverse bulk updates?

The research notes describe 100 to 1,000 records as a common range for standard-table guidance and about 100 for elastic tables. These are not universal settings; test sizes against payload and processing time.

Can Dataverse plug-ins slow down a bulk update?

Yes. Synchronous plug-ins and other server-side logic can contribute substantially to processing time. A bulk request does not automatically remove that work.

What should I do if a Dataverse bulk request is throttled?

The research notes say a Web API HTTP 429 response includes a Retry-After value. Honor that delay instead of retrying immediately, and control concurrency.