10.1 Cross-Domain "Where Do I Implement This?" Decision Framework
Key Takeaways
- 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
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.
A requirement states that a field must be validated and auto-populated whenever a record is created or updated, regardless of whether the change comes from the model-driven app, a Power Automate flow, or a direct Dataverse Web API call made by an external system. Which mechanism should the developer choose?
A developer needs to run a bulk data-transformation job that takes about eight minutes to complete, automatically every night at 2 AM, with no user present to trigger it. Which design satisfies these requirements without violating platform limits?