Every night an external system delivers about 300,000 product price updates. The current design runs one cloud flow per record, which takes hours and regularly hits service protection limits. Which redesign best addresses throughput and reliability?
Select an answer to reveal the explanation.
Short Explanation
Think of the per-record flow as moving house one sock at a time. Your Azure-hosted code with UpdateMultiple loads whole boxes, and when Dataverse says 'slow down' with Retry-After, it actually listens. The trap is just adding more parallel flows, which hits the limits even harder.
Full Explanation
Large inbound loads are best handled by server-side integration code, for example an Azure function or job, that uses Dataverse bulk operation messages. UpdateMultiple and CreateMultiple send many rows of the same table in a single request and are optimized for throughput, delivering far more work per request than individual updates under the same service protection limits. Combined with a reasonable degree of parallelism and a retry policy that waits for the duration in the Retry-After header when a 429 response arrives, the load completes faster and more reliably. Increasing flow concurrency and splitting the work into more flows multiplies requests against the same limits, causing more throttling rather than less, and each record still pays per-run overhead. Running the load inside a plug-in is unsuitable: plug-ins have a short execution time limit, and Microsoft advises against using ExecuteMultiple within plug-ins because it holds the transaction and degrades performance. Adding delays between per-record flows reduces throttling only by slowing everything down, which makes the window longer. Exam caveat: bulk messages work best with batches of a sensible size, and the same pattern applies when moving to elastic tables. Operational check: run the job against a test environment, review 429 counts and total duration, and confirm Retry-After waits occur in the logs.