When a project row's status changes to Approved, the solution must call three external services, aggregate their responses, and write results back to Dataverse. The processing can take several minutes, and the user saving the row must not wait for it. Which design should the developer choose?
Select an answer to reveal the explanation.
Short Explanation
When your work takes minutes, don't make Dataverse babysit it. Drop a message on a Service Bus queue and let an Azure Function do the heavy lifting on its own time. Plug-ins have a hard two-minute ceiling, so any design that keeps the work inside one is betting against the clock.
Full Explanation
Dataverse plug-ins, synchronous or asynchronous, are limited to two minutes of execution, and they share resources with the platform, so long-running orchestration does not belong inside them. A durable decoupled pattern registers a service endpoint for Azure Service Bus, posts the execution context to a queue when the status changes, and lets an Azure Function with a Service Bus trigger process each message. The function can call external services for as long as its hosting plan allows, retry failures, and write results back through the Web API or SDK using its own identity, while the user's save completes immediately. A synchronous PostOperation plug-in keeps the user's transaction open while external calls run, exposing the save to the two-minute timeout and rolling it back on any failure. An asynchronous plug-in removes the user wait but remains subject to the same timeout, and sleeping inside it wastes sandbox resources while still failing on slow services. Client script on OnSave runs only when the form is used, so imports, flows, and API updates would never trigger the processing, and the browser cannot reliably run multi-minute work. Exam caveat: queue-based messaging adds dead-letter handling that should be monitored. Operational check: change a test row's status and confirm a message lands on the queue and the function's results are written back.