1.5 Designing Dataverse Code Components, Automations, and Integrations

Microsoft Power Platform Developer Associate PL-400

Track your progress as you read

Finished sections get a check mark.

1 Introduction, Exam Overview & Developer Toolchain

0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow

2 Create a Technical Design

1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations

3 Build Power Platform Solutions

2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools

4 Implement Power Apps Improvements

3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance

5 Extend the User Experience

4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component

6 Extend the Platform: Dataverse Plug-ins & Custom APIs

5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events

7 Extend the Platform: Custom Connectors

6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation

8 Extend the Platform: Platform APIs & Azure Functions

7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities

9 Extend the Platform: Power Automate Cloud Flows

8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals

10 Develop Integrations

9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message

11 Exam Readiness & Practice

10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan

1.5 Designing Dataverse Code Components, Automations, and Integrations

Key Takeaways Explain This Topic AI

Power Fx formula columns, plug-ins, and custom APIs form a low-to-high code spectrum for Dataverse-side logic, chosen based on whether side effects and transactional guarantees are required.

A custom API's logic can be implemented by either a plug-in (synchronous, code-based) or a Power Automate flow (maker-maintainable), which is a key design tradeoff.

Automated, instant, and scheduled cloud flows serve different automation triggers, from data-change reactions to user-initiated actions to batch jobs.

Inbound integrations reach Dataverse via the Web API, connectors, or virtual tables; outbound integrations publish via plug-ins to Azure Service Bus/Event Hub, business events, or flow-triggered connector calls.

Every integration point in a technical design must be checked against the authentication and security design so no entry point bypasses the intended access controls.

Last updated: July 2026

The final piece of technical design is deciding how Dataverse-side logic is packaged for reuse and how the solution talks to systems outside the Power Platform. This spans three related design areas: Dataverse code components, Power Automate automations, and inbound/outbound integrations with Azure.

Designing Dataverse Code Components

Three mechanisms let a Dataverse solution run custom logic, ordered here from lowest to highest code investment:

Power Fx formula columns compute a value declaratively using Power Fx expressions evaluated by Dataverse itself, with no plug-in assembly to deploy. They are the right design choice whenever the "custom logic" is really just a computed value (a total, a concatenation, a conditional label) rather than a side effect or external call.

Plug-ins are compiled .NET assemblies registered against the Dataverse event pipeline (covered in depth in the plug-in domain) and are the right choice for logic with side effects — validating and blocking a save, updating related records, or calling the Organization service — that must run consistently for every caller.

Custom APIs define a brand-new, strongly typed message (with declared input/output parameters) that becomes callable through the Web API and SDK just like a built-in message such as Create or Update . A custom API can be bound to a specific table (appearing as an action on that entity) or unbound (a global operation). Critically, a custom API's logic can be implemented either by a plug-in or by a Power Automate flow registered as its processing step — this flexibility is a frequent design decision point, since a flow-backed custom API is easier for a low-code team to maintain, while a plug-in-backed one runs synchronously with full transactional guarantees.

Designing Automations with Power Automate Cloud Flows

Cloud flows are the automation layer for logic that is really an orchestration rather than a single-table rule. Design decisions include:

Flow type Trigger Design use
Automated Dataverse event (create/update/delete) or connector event React to data changes across systems
Instant Manual button (Power Apps or Teams) User-initiated one-off actions
Scheduled Recurrence Batch jobs, periodic sync, cleanup

When designing a flow-based automation, decide up front whether the flow needs to be synchronous from the user's perspective (in which case an instant flow triggered from the app, with the app waiting on a response, may be needed) or can run fully asynchronously in the background (a Dataverse-triggered automated flow).

Designing Inbound and Outbound Integrations

Integration design splits into two directions, both of which typically involve Azure services alongside native Dataverse capability.

Inbound (external system → Dataverse)

Dataverse Web API — the standard OData v4 REST endpoint external systems call directly, authenticated via Entra ID (see the authentication section).

Standard or custom connectors — external systems reached from a Power Automate flow rather than Dataverse being called directly.

Virtual tables — external data surfaced as if it were Dataverse data, avoiding duplication for read-heavy scenarios (see the data modeling section).

Outbound (Dataverse → external system)

Plug-ins registered on service endpoints publish Dataverse events to Azure Service Bus (queues or topics) or Azure Event Hub , decoupling Dataverse from the receiving system entirely — the receiver picks messages up independently, and Dataverse doesn't need to know it exists.

Dataverse business events and webhooks let external listeners subscribe to platform events without a full plug-in registration, using a lighter-weight subscription model.

Power Automate flows triggered by Dataverse changes can call outbound connectors directly, which is often simpler to build and maintain than a Service Bus-based plug-in pipeline, at the cost of being tied to the Power Automate runtime rather than a pure messaging backbone.

Choosing an Integration Pattern

Need Recommended pattern
Real-time, guaranteed, decoupled outbound event delivery Plug-in → Azure Service Bus/Event Hub
Simple outbound notification to a known set of systems Power Automate flow triggered by Dataverse event
Read-only access to external data without duplication Virtual table
External system writing directly into Dataverse Web API with Entra ID app registration
Exposing custom Dataverse logic as a callable operation Custom API (plug-in- or flow-backed)

A complete technical design names the specific pattern for every integration point in the requirements, states which Azure resources (if any) are involved, and confirms the authentication and security design from earlier sections covers every one of those entry points — an integration that bypasses the security model designed for the UI is a common, exam-relevant design flaw.

Sequencing the Design Work

In practice, these three design areas are not chosen independently — they build on each other in sequence. First decide what kind of Dataverse code component the logic needs (formula column, plug-in, or custom API), because that decision determines whether the logic can even be reached from outside Dataverse. Then decide whether an automation (a cloud flow) is orchestrating around that code component or is the entire solution by itself. Only after both are settled does the integration direction matter: an inbound integration typically calls a custom API or the Web API directly, while an outbound integration is typically triggered by the same plug-in or flow that already enforces the business logic, rather than being bolted on as a separate, uncoordinated mechanism. Designing these three areas together, instead of one at a time, is what keeps a solution's automation and integration surface consistent and auditable.