An asynchronous Dataverse plug-in enriches each new lead by calling a slow third-party data service, sometimes several times per lead. As volume grows, the plug-in increasingly fails with timeout errors and the system jobs pile up. The enrichment does not have to finish within any fixed time. What should the developer do?

Asynchronous plug-ins run outside the user's transaction, but they remain sandboxed and limited to two minutes of execution per run. Work that depends on a slow external service, repeated calls, or unpredictable volume does not fit that limit, and failed system jobs then consume asynchronous service capacity for everyone. The supported pattern is to keep Dataverse responsible only for publishing the event, through a service endpoint registered for Azure Service Bus, and to perform enrichment in an Azure Function that scales with queue depth, retries failed calls, and writes results back. Switching the step to synchronous gives it no extra time; the same execution limit applies, and the user's create now waits and fails along with it. Chaining steps on Depth does not split work safely; Depth tracks recursion, and spreading calls across nested executions creates fragile coupling and possible infinite loops. The Plug-in Registration Tool exposes no setting that raises the sandbox execution timeout for a plug-in, so tuning there cannot solve the problem. Exam caveat: business events or webhooks are alternatives for the handoff, but the processing itself still belongs in a service built for long-running work. Operational check: after the change, confirm the plug-in step is gone or only posts, and that queue depth and function failures are monitored with alerts.