Study guide
10.1 Cross-Domain "Where Do I Implement This?" Decision Framework
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
10.1 Cross-Domain "Where Do I Implement This?" Decision Framework
Key Takeaways Explain This Topic AI
The exam allocates weight across six domains, with Extend the platform the heaviest at 30-35% - plug-ins, custom APIs, connectors, platform APIs, Azure Functions, and cloud flows combined
Default to no-code or low-code logic (business rules, Power Fx) whenever a requirement can be met without custom code; reserve pro-code (plug-ins, PCF, Azure Functions) for logic outside the platform's declarative reach
Synchronous, transactional logic that must block or modify the operation belongs in a plug-in; asynchronous, long-running, or multi-system orchestration belongs in a cloud flow or Azure Function
A custom API is the right choice when server-side logic must be reusable and callable by name from multiple clients - JavaScript, Power Automate, and external systems alike - rather than tied to one record event
Sandboxed plug-ins are capped at a two-minute execution limit, which is the single fact that most often decides between a plug-in and an Azure Function on scenario questions
Last updated: July 2026
Cross-Domain "Where Do I Implement This?" Decision Framework
Quick Answer: PL-400 scenario items rarely test one fact in isolation - they describe a requirement and expect you to pick the right extension mechanism from six or more plausible options (business rule, Power Fx, client script, plug-in, custom API, cloud flow, Azure Function, custom connector, or PCF component). This section builds a reusable decision framework, applies it to mixed scenarios, and closes with a cross-domain high-yield fact list.
Recap: The Six PL-400 Domains and Their Weight
Before drilling into decision logic, keep the exam blueprint's shape in view. Every scenario question is really asking you to place a requirement into one of these six functional groups.
- # Domain Weight Chapters in this guide
- 1 Create a technical design 10-15% Chapter 1
- 2 Build Power Platform solutions 10-15% Chapter 2
- 3 Implement Power Apps improvements 10-15% Chapter 3
- 4 Extend the user experience 10-15% Chapter 4
- 5 Extend the platform 30-35% Chapters 5-8
- 6 Develop integrations 10-15% Chapter 9
Extend the platform is worth roughly as much as the other five domains combined at their low end, and this guide spends four full chapters there - plug-ins and custom APIs (Chapter 5), custom connectors (Chapter 6), platform APIs and Azure Functions (Chapter 7), and cloud flows (Chapter 8). If your remaining study time isn't weighted toward that domain, rebalance before exam day.
The "Where Do I Implement This?" Decision Framework
Most PL-400 scenario questions can be answered by asking four questions, in order: Can this be done without code? Must it run synchronously inside the database transaction? Does it need to run longer than a few minutes or on a schedule? Does it need to be reusable and callable by name from multiple clients? The table below maps requirement patterns to the mechanism the exam expects.
Requirement pattern Best mechanism Why not the alternatives
Simple field validation, default, or show/hide logic Business rule Power Fx and plug-ins add unnecessary code for logic the no-code designer already covers
Reusable calculation logic across a canvas app or component library Power Fx (formula or component) Plug-ins only fire against Dataverse - they can't evaluate inside a canvas app's client-side engine
Must run synchronously, inside the platform transaction, and block or modify the operation Plug-in Cloud flows and Azure Functions are asynchronous by default and can't roll back the transaction
Callable by name, with typed parameters, from JavaScript, a flow, and external systems alike Custom API A plug-in tied to one message/entity event isn't directly invokable on demand
Long-running (multi-minute), CPU-intensive, or needs to scale independently Azure Function Sandboxed plug-ins are capped at two minutes; cloud flow actions time out first too
Orchestrates multiple systems, needs approvals/retries, or a scheduled trigger without blocking the save Cloud flow Plug-ins block the save until they finish - wrong for slow, multi-step orchestration
Client-side UI behavior - hide fields, call the Web API from a form, drive command-bar buttons Client script Business rules can't make Web API calls or implement complex conditional logic
Custom interactive control needing device features (camera, geolocation, offline storage) PCF component Client scripts can modify existing controls but can't render a new interactive UI surface
Wrapping or calling an external REST API from Power Apps or Power Automate Custom connector (backed by an Azure Function if transformation is needed) A plug-in can't be invoked from a canvas app; a bare flow action can't describe the API's auth and operations to the platform
Mixed-Scenario Walkthroughs
Case-study questions layer two or three of these patterns together. Work through them the way the exam expects:
Scenario A - validation against an external system. A sales record must be checked against a third-party tax-rate API before saving, whether the record comes from the model-driven app, a data import, or a partner integration. A business rule can't call an external API, and a client script won't run for a server-to-server import. The fix is a plug-in registered on Create/Update (Pre-operation, synchronous) calling the tax service through a custom connector - and if that call is too slow for the two-minute sandbox budget, shift to asynchronous validation via a cloud flow that flags exceptions instead.
Scenario B - long-running work from a canvas app. A canvas app must kick off an eight-minute document-generation job without freezing the UI, then email the user when done. Canvas apps can't run long server jobs directly, and a synchronous plug-in would blow past its limit. The shape: canvas app calls a cloud flow , the flow starts an Azure Function to do the work asynchronously, and a completion signal sends the notification.
Scenario C - one operation, many callers. A reusable "approve and notify" operation must be callable identically from a command-bar button, a batch script, and a partner's external system. That's the signature use case for a custom API - a named, reusable operation with typed parameters - not a plug-in tied to one event or a flow only one caller can trigger.
Cross-Domain High-Yield Facts to Memorize
These facts span multiple chapters and show up repeatedly as scenario-question distractors:
Plug-in pipeline stages: Pre-validation (stage 10 , outside the database transaction - security checks before locks are taken), Pre-operation (stage 20 , inside the transaction, can modify the target record), Main operation (stage 30 , the platform's own core operation - not extensible by plug-ins), Post-operation (stage 40 , inside or outside the transaction depending on synchronous vs. asynchronous registration).
Sandbox execution limit: sandboxed plug-ins and custom workflow activities are capped at two minutes ; exceeding it throws a timeout exception, which is exactly why genuinely long operations belong in an Azure Function instead of a plug-in.
Power Fx delegation: delegable queries push filtering and sorting to Dataverse itself; non-delegable formulas trigger a design-time warning and silently truncate results at the delegation limit (default 500 rows, adjustable but not recommended much past 2,000).
Managed vs. unmanaged solutions: unmanaged solutions belong only in development environments, since they're the "raw," directly-editable layer; managed solutions are the only supported way to deploy to test, UAT, and production, and at runtime only the top managed layer's customizations for a component are active.
Keep this framework in mind as you move into the exam-day mechanics and study plan in the next section.