Problem Statement
Dataverse plug-ins (synchronous and asynchronous) are subject to a hard 2-minute execution limit in the sandbox. When a plug-in exceeds this limit, Dataverse throws a System.TimeoutException (error code 0x80040224) and rolls back the entire transaction.
While this limit protects platform stability, it creates significant challenges for legitimate business scenarios that involve processing a parent record with a large number of related child records in a single operation - such as:
- Generating credit notes against an Invoice with hundreds of invoice lines
- Cascading updates from a parent entity to its related records during a business process
- Bulk financial calculations triggered by a single approval action
- Complex Field Service or Project Operations workflows involving many child entities
In these cases, the work is logically a single transaction from a business standpoint, but the platform forces it to be artificially broken up into chained operations.
Customer Impact
- Customers must invest significant development effort to redesign existing plug-ins that previously worked at lower data volumes but began failing as the business grew
- Business users experience operational delays and rollbacks when processing realistic data volumes
- ISV partners must rebuild solutions using Custom APIs, Power Automate orchestration, or Azure Functions purely to work around the limit - adding architectural complexity and maintenance overhead
- The 2-minute limit is non-configurable even when customers are willing to accept the trade-offs (e.g., longer transaction visibility, slightly higher resource usage)
Proposed Solution
We would like Microsoft to consider one or more of the following enhancements:
- Configurable execution timeout per environment or per plug-in step. e.g., allow admins to extend the limit to 5 or 10 minutes for specific high-volume scenarios, with appropriate governance/throttling safeguards.
- A new "long-running" plug-in execution mode: explicitly designed for batch/bulk-style server-side logic, executed outside the standard sandbox constraints (perhaps similar to elastic jobs).
- Built-in chained execution / continuation pattern: a first-class platform feature that automatically resumes a plug-in's processing across multiple 2-minute windows without requiring custom orchestration code, cursors, or Power Automate loops.
- Improved native batching API for parent-child operations: a Dataverse-aware mechanism that handles "process this parent + all its related children" cleanly under one logical request, automatically partitioning the work server-side.
Business Value
- Reduces the need for complex, custom architectural workarounds for what are very common business scenarios
- Lowers the total cost of ownership for Dynamics 365 / Power Platform solutions
- Improves the experience for ISVs and customers scaling their solutions over time
- Aligns Dataverse server-side capabilities with the increasing data volumes seen in real-world enterprise deployments
Customer Current Status
A customer running Dynamics 365 Field Service uses a custom plug-in (CreditNoteInvoice) registered on a Custom Action against the OOTB Invoice entity. The plug-in is triggered when a user generates a credit note, and it processes all related invoice line items in a single transaction. As the business grew, individual Invoices began carrying significantly more line items, causing the plug-in to consistently exceed the 2-minute platform limit and throw System.TimeoutException. The customer must now redesign the solution using batching or Custom API + Power Automate orchestration. Even though, from a business perspective, this is a single user-initiated action that should complete reliably regardless of data volume.
Supporting Documentation
- https://learn.microsoft.com/en-us/power-apps/developer/data-platform/analyze-performance
- https://learn.microsoft.com/en-us/power-apps/developer/data-platform/best-practices/business-logic/
- https://learn.microsoft.com/en-us/power-apps/developer/data-platform/custom-api