Low-code plug-ins in Dataverse

Traditional Dataverse plug-ins are C# assemblies registered against table events, requiring developer skills, Visual Studio, and a build/deploy pipeline. Low-code plug-ins offer the same server-side execution model but written in Power Fx by makers — collapsing the developer dependency for many extension scenarios.

Two flavours of low-code plug-in.

• Instant plug-in — invoked explicitly (from a Power Automate flow, a model-driven command, a custom button). Acts like a Power Fx-defined custom action.
• Automated plug-in — fires on row events (Create, Update, Delete) before or after the database commits the change. Acts like a traditional plug-in but Power Fx instead of C#.

Where they fit in the spectrum.

• Business rule — runs in the client form, simple field manipulation. Doesn't run from API.
• Power Automate cloud flow — async or sync orchestration, integrates with hundreds of connectors. Higher overhead per invocation; not transactional with the Dataverse operation.
• Low-code plug-in — server-side, sync with the Dataverse operation, Power Fx authoring. Sweet spot for in-transaction logic without dev complexity.
• Traditional C# plug-in — full .NET, most extensibility, hardest to author and maintain.

The low-code plug-in fills the gap between "this needs to run server-side and inside the same transaction" and "I don't want to maintain C# code."

What you can do in a low-code plug-in.

• Set field values on the operation's row.
• Cancel the operation with an error message (validation).
• Read related records via lookups.
• Update related records (within plug-in limits).
• Call Power Fx functions for date math, text manipulation, lookups.
• Trigger downstream through Power Automate by writing to a queue or notification table.

What you can't do well.

• External API calls — limited.
• Complex multi-step orchestration — Power Automate is better suited.
• Heavy compute — Power Fx has performance ceilings.
• Long-running operations — plug-in execution is bounded; multi-second logic gets killed.

Creating an instant plug-in. In the maker portal:

1. Solutions → New → More → Low-code plug-in.
2. Type: Instant.
3. Define input parameters and output parameter.
4. Author Power Fx logic.
5. Save and publish.

The plug-in registers as an action; Power Automate flows can call it, model-driven buttons can invoke it, an HTTP call can reach it.

Creating an automated plug-in. Same start, then:

1. Type: Automated.
2. Select the table.
3. Select the event (Create, Update, Delete).
4. Stage: Pre-operation or Post-operation.
5. Filter conditions if needed.
6. Author Power Fx logic.

The plug-in fires automatically on every matching event.

Pre vs post.

• Pre-operation — runs before the database commits. Can mutate the incoming row or cancel the operation.
• Post-operation — runs after commit. Used for derived updates and triggering downstream work.

For validation logic, use pre. For populating related records, use post.

Performance considerations. Plug-ins run synchronously with the Dataverse operation. Slow plug-ins slow every Create/Update/Delete on the table. Power Fx adds some overhead vs C#, so very high-volume tables (1000+ writes per minute) may need C# for raw performance.

Comparison to Power Automate triggers. A Power Automate flow can also trigger on Dataverse events:

• Async by default — runs out of band from the user's action.
• Cross-connector integration — call Outlook, SharePoint, external APIs.
• More observable — run history, troubleshooting tooling.

Power Automate is the better choice for orchestration across systems. Low-code plug-ins win when:

• The logic must complete within the transaction.
• The validation must block the operation.
• The performance overhead of cross-process invocation matters.

Solution awareness. Low-code plug-ins live in solutions; they deploy through the ALM pipeline like other components. They can reference Power Fx custom logic functions, connection references, and environment variables, integrating with the broader ALM story.

Common pitfalls.

• Using post-op when pre-op was needed. Validation in post fires too late; the bad data is already saved.
• Calling external APIs from a plug-in. Latency cascades; the user-facing operation slows.
• No error handling. Power Fx error propagation can be silent; users see operation succeed when business logic failed.
• Plug-in chains. Plug-in A updates table X; another plug-in on X fires; cascade not controlled; performance issues or unintended recursion.
• Treating low-code as a complete substitute for traditional plug-ins. Some scenarios still demand C# — accept the boundary.

Operational guidance. Default to low-code plug-ins for new server-side logic — faster to author, easier to maintain, ALM-friendly. Reach for C# only when low-code clearly can't meet the requirement: heavy compute, complex external integrations, or performance-critical paths. Most environments end up with a mix; the boundary depends on the team's developer skill and the workload's complexity.