Most Dynamics 365 development teams have at least one plug-in that fails silently in production, taking 72 hours to surface as a data consistency issue. The culprit is rarely bad logic. It’s usually that the plug-in was built for a demo scenario (one record per execution) and now runs against datasets that number in the millions, with network timeouts, throttling, and concurrent executions that the original code never anticipated.

Building plug-ins that survive production load requires rethinking how you structure them. It means moving beyond the synchronous, tightly-coupled patterns that dominate most examples online, and adopting async-first design, proper dependency injection, and layered error recovery that prevents one bad external call from cascading into broader system failure.

The Synchronous Plug-in Problem

The standard pattern that most developers learn looks like this: register a synchronous plug-in on Create, make a direct call to an external API or Azure function, handle exceptions in a try-catch, and if something goes wrong, throw an InvalidPluginExecutionException that rolls back the transaction. It works fine at pilot scale.

In production, this approach breaks in at least three predictable ways. First, synchronous calls to external APIs introduce latency into the critical path: if your external service takes 2-3 seconds per call and you have 1,000 records coming in during end-of-month close, you’ve added 30-50 minutes of cumulative wait time to the operation. Dataverse request limits start hitting, timeouts fire, and the whole batch fails.

Second, exceptions thrown from a synchronous plug-in roll back the entire transaction. If your plug-in calls a third-party tax service that fails for 1% of addresses, that 1% causes the entire create operation to fail. The user gets an error message, and business logic that should have completed gets undone, leaving data in an inconsistent state.

Third, synchronous plug-ins run within the context of the user’s operation. If performance issues, timeouts, or external system failures occur, the user sees the delay. At scale, this creates a user-facing reliability problem that no amount of exception handling can mask.

The Async-First Pattern

Production-grade Dataverse plug-in architecture flips the script: perform only fast, local validation in the synchronous plug-in, then hand off all external work to asynchronous processing. The synchronous portion validates the record’s data and business rules, completes within milliseconds, and succeeds unless validation fails. External calls, enrichment, downstream integrations, and data reconciliation all move into asynchronous jobs that run on their own schedule.

This requires two components. The synchronous plug-in itself becomes minimal: it checks that required fields are populated, validates against business rules (minimum order quantity, customer status, etc.), and if validation passes, creates a work queue entry (typically a custom table in Dataverse) and returns success to the user immediately. The user sees success, the record is created, and life continues.

The asynchronous processor is a separate service: either an Azure Function triggered by a Dataverse plugin step (via a message or webhook), a Power Automate cloud flow running on a schedule, or a dedicated service listening to a queue. This processor reads the queue entry, makes external calls with full error recovery, retries intelligently, and logs outcomes. If the external call fails, it updates the queue entry status, alerts the right team, and stops. The core transaction never rolls back.

This architecture buys you two critical advantages. First, user-facing operations stay fast and predictable, regardless of external system health. Second, failures are isolated and recoverable. One failed tax lookup doesn’t block the entire close process. You handle it asynchronously, resolve it, and reprocess.

Implementing Dependency Injection in Plug-ins

Synchronous plug-ins traditionally create dependencies inline: instantiating HTTP clients, database connections, or service proxies directly inside the Execute method. This couples the plug-in code to concrete implementations and makes testing nearly impossible.

Modern plug-in architecture uses a service container or dependency injection (DI) pattern, even though Dataverse’s plugin sandbox doesn’t natively provide one. The workaround is straightforward: create a static factory or service locator that lazy-loads dependencies on first use, and document the dependencies clearly so future developers understand what the plug-in needs.

An example: a plug-in that enriches lead records might depend on a geography service (to resolve addresses to territories), a compliance checker (to flag high-risk industries), and a logger (to track enrichment outcomes). Rather than instantiating these inside the plug-in, you define an interface for each and inject them through a constructor or factory. This pattern makes testing straightforward: mock the interfaces, pass them to the plug-in, and test the business logic in isolation from external dependencies. In production, the factory provides the real implementations.

Error Recovery and Observability

Unhandled exceptions in a plug-in either surface to the user (if synchronous) or silence themselves (if asynchronous and not logged). Either way, production debugging becomes a nightmare if you don’t have visibility into what happened.

Production plug-ins should log four categories of information: entry and exit points (plug-in started, completed successfully), validation failures (rule X failed for reason Y), external service failures (call to service Z failed with status code W), and unexpected exceptions (full stack trace, input data for reproduction). Use Application Insights, a custom Dataverse log table, or a centralized logging service; the medium matters less than the consistency and searchability.

For error recovery, the strategy depends on whether the failure is transient or permanent. Transient failures (network timeouts, HTTP 429 too-many-requests, HTTP 503 service-unavailable) warrant exponential backoff and retry: pause 1 second, try again; if it fails, pause 2 seconds, try again; if it fails, pause 4 seconds, try again. After 3-5 retries, treat it as a permanent failure and escalate.

Permanent failures (HTTP 400 bad request, HTTP 401 unauthorized, HTTP 404 not found) should not retry. They indicate a configuration error, missing data, or infrastructure problem that retry won’t fix. Log them clearly, escalate to the on-call team, and stop processing for that record until the underlying issue is resolved.

Dataverse Throttling and Concurrency

Plug-ins run within Dataverse’s throttling limits: 15 concurrent requests per organization. If a plug-in takes 10 seconds to run and makes synchronous external calls, it saturates these slots instantly, and subsequent operations queue up and timeout.

Asynchronous processing, paired with careful concurrency control, avoids this. The asynchronous processor runs outside Dataverse’s request limits and can handle hundreds of queued items without blocking users. It processes them sequentially or in small batches, respecting the external service’s rate limits as well.

Building for Production

Production-grade Dataverse plug-in development isn’t complex. It requires four habits: keep synchronous plug-ins minimal and fast, move external work to asynchronous processors, log everything, and handle errors explicitly by type (transient vs. permanent). This architecture scales to millions of records, survives external system failures, and keeps end users seeing consistent, predictable performance.

Routeget Technologies has guided dozens of organizations through this transition, moving from brittle, demo-scale plug-ins to resilient, enterprise-grade integration architectures that handle real-world scale and complexity.

#DynamicsPluginDevelopment #DynamicsIntegration #DataverseArchitecture #PluginPatterns #ErrorHandling #AsyncPatterns #DependencyInjection #EnterpriseArchitecture #DynamicsEngineering