Dynamics 365 CE gives a delivery team many ways to change system behavior. That flexibility is useful, but it also creates a recurring architecture question: where should a requirement live?
The answer is rarely “always use low code” or “put it in a plugin.” A better decision starts with the business event, the required guarantee, and the team that will operate the result.
Begin with configuration
Use native configuration when the platform already expresses the rule clearly. Tables, forms, views, business rules, security roles, and process configuration are visible to administrators and reduce custom maintenance. Native configuration is often the most supportable engineering choice.
The boundary appears when a rule needs complex validation, cross-record consistency, transaction control, reusable domain logic, or behavior that native components cannot express safely.
Use Power Automate for observable orchestration
Power Automate works well when a process is asynchronous, integration-oriented, and valuable to monitor as a sequence of actions. Notifications, approvals, document movement, and calls to external services are common examples.
Before choosing a flow, ask what happens when a step runs twice, fails halfway, or receives data in an unexpected order. Retry behavior, idempotency, connection ownership, environment variables, and support visibility are part of the design.
Use plugins for server-side guarantees
A Dataverse plugin is appropriate when logic must run close to the data operation, enforce a rule consistently across clients, or participate in a transaction. Plugins can provide strong control, but that control comes with responsibility for execution time, recursion, exception handling, registration, tracing, and deployment.
Keep plugin responsibilities narrow. A plugin that performs large external operations synchronously can turn an application save into a fragile distributed transaction. Where possible, enforce the immediate invariant in the plugin and move slower orchestration to an asynchronous boundary.
Use PCF and client scripting for interaction
PCF controls and client-side code should improve how a user works with data, not become a second hidden business layer. They are useful for specialized visualization, guided input, and interaction patterns that standard controls cannot provide.
Any business rule implemented only in the browser can be bypassed by another integration or client. If the rule protects data integrity, it also needs a server-side home.
Use external services when the boundary is real
External .NET services are justified when the work requires independent scaling, specialized libraries, long-running processing, a separate security boundary, or integration ownership outside Dataverse. The service contract, authentication, monitoring, and failure model then become first-class architecture.
A practical decision sequence
- Can native configuration express the behavior clearly?
- Is the work asynchronous orchestration that benefits from visible flow history?
- Does the rule require a server-side or transactional guarantee?
- Is the requirement primarily about user interaction?
- Does it belong to an independently operated service boundary?
The right extension point is the smallest one that satisfies the required guarantee and remains understandable to the team that will own it.
This framework is grounded in my Dynamics 365 customer platform work and Power Platform expertise.