Power Platform ALM & DevOps (PL-400) — Complete Guide
Technical Design · Dataverse Plugins · PCF Controls · Custom Connectors · ALM · Pipelines · Power Platform CLI · Azure DevOps · Scenarios · Cheat Sheet
Top Hashtags: #PowerPlatformALM, #PL400, #PowerPlatformDeveloper, #PowerPlatform, #DataversePlugins, #PCFControls, #PowerPlatformCLI, #ALMPowerPlatform, #LowCode, #MicrosoftDeveloper
Table of Contents
- Exam Overview & Technical Design (10–15%)
- Build Power Platform Solutions (10–15%)
- Extend the User Experience (10–15%)
- Extend the Platform — Plugins & APIs (40–45%)
- Power Platform ALM & DevOps
- Develop Integrations (5–10%)
- Scenario-Based Questions
- Cheat Sheet — Quick Reference
1. Exam Overview & Technical Design (10–15%)
PL-400 Exam at a Glance
The PL-400 Microsoft Power Platform Developer exam validates expertise in designing, developing, testing, and troubleshooting Power Platform solution components using extension points. Candidates should be proficient in Microsoft Power Platform services, C#, JavaScript, TypeScript, JSON, HTML, RESTful Web APIs, and Azure.
| Skill Domain | Exam Weight |
|---|---|
| Create a technical design | 10–15% |
| Build Power Platform Solutions | 10–15% |
| Implement Power Apps improvements | 5–10% |
| Extend the user experience | 10–15% |
| Extend the platform | 40–45% ← LARGEST |
| Develop integrations | 5–10% |
Key fact: Extend the platform is 40–45% of the exam. Prioritise: Dataverse plugins (C#), custom connectors, Power Platform CLI, ALM, and Dataverse Web API.
How do you decide between low-code and pro-code in Power Platform?
Decision framework: Low-code vs Pro-code
Always try low-code first (cheaper, faster, maintainable by citizen devs):
→ Standard Power Apps (canvas or model-driven) for the UI
→ Power Automate cloud flows for automation
→ Dataverse built-in business rules for simple field validation
→ Dataverse calculated/rollup columns for derived values
When to escalate to pro-code:
→ Complex server-side business logic requiring ACID transactions
→ Use: Dataverse C# Plugin
→ Performance-critical real-time validation across multiple tables
→ Use: Dataverse C# Plugin (synchronous pre-operation)
→ Custom UI control behaviour beyond standard controls
→ Use: PCF (Power Apps Component Framework) control
→ Connect to a service with no existing connector
→ Use: Custom Connector (OpenAPI/Swagger definition)
→ Long-running or complex operations with Azure infrastructure
→ Use: Azure Function called from plugin or Power Automate
→ Batch data processing or complex ETL
→ Use: Azure Function or Azure Logic App
Architecture decision checklist:
1. Can it be done with out-of-the-box Power Platform? → Do it low-code
2. Needs server-side logic run on create/update/delete? → C# Plugin
3. Needs a custom UI component? → PCF Control
4. Needs external system not in connector gallery? → Custom Connector
5. Needs Azure compute, ML, or AI? → Azure Function + connector
6. Needs human approval + complex branching? → Power Automate flow
What is the Power Platform solution structure and types?
Solutions:
→ Container for customisations and components that can be transported
between environments (Dev → Test → Production)
→ Everything deployable must be inside a solution
Solution types:
Unmanaged solution:
→ Used in DEVELOPMENT environments only
→ All components editable
→ No version enforcement
→ Contains references to components (not copies)
→ Can be exported as unmanaged (.zip) for source control
Managed solution:
→ Deployed to TEST and PRODUCTION environments
→ Components are READ-ONLY (cannot be edited directly)
→ Version enforced — only newer version can replace it
→ Uninstalling removes all components cleanly
→ Created by exporting an unmanaged solution as managed
Key decision: NEVER develop in managed solution environments
NEVER deploy unmanaged solutions to production
Solution components (what can be inside a solution):
Tables (entities), columns (fields), relationships
Views, forms, charts, dashboards
Cloud flows, canvas apps, model-driven apps
Security roles, environment variables, connection references
Plugins, custom workflow activities, web resources
PCF controls, custom connectors, dataflows
Environment variables:
→ Store environment-specific configuration (URLs, keys, thresholds)
→ Different values per environment (Dev/Test/Prod) without code change
→ Types: string, number, boolean, JSON, data source
→ Referenced in: flows, plugins, canvas apps, cloud flows
Connection references:
→ Abstractly reference a connector (instead of hardcoding a connection)
→ When solution deployed: admin configures the actual connection
→ Enables the same flow to connect to different accounts per environment
→ Always use connection references instead of direct connections in flows
2. Build Power Platform Solutions (10–15%)
How do you configure Dataverse tables and relationships for complex solutions?
Dataverse table types:
Standard table: most tables — PK is a GUID, full Dataverse features
Activity table: special type for activities (email, task, appointment)
enables activity timeline, sender/recipient model
Elastic table: designed for high-volume, time-series or IoT data
uses Cosmos DB underneath — horizontal scale
Virtual table: maps to external data source (SQL, OData, etc.)
appears as Dataverse table, queries external system live
Relationship types:
One-to-many (1:N): one parent row → many child rows
creates a lookup column on the child table
e.g., Account (1) → Contacts (N)
Many-to-many (N:N): via an intersect (junction) table
e.g., Contacts ↔ Marketing Lists
Use: relate records without a hierarchy
Polymorphic lookup: lookup that can point to multiple table types
e.g., Regarding field on Activity — can be Account,
Contact, Lead, or Opportunity
Column types:
Simple: Text, Number, Date, Choice (picklist), Lookup, File/Image
Calculated: value computed from formula (no triggers, re-computed on read)
Rollup: aggregate from child records (sum, count, avg, min, max)
runs on a schedule (hourly) — not real-time
Formula: Power Fx expressions (Dataverse-native, new)
Auto-number: automatically incremented unique identifiers
Business rules (no-code server + client logic):
→ Set field values, show/hide fields, validate values, lock fields
→ Scope: entity (server-side — always runs) or form (client-side only)
→ Cannot: query other tables, send emails, perform HTTP calls
→ For complex logic: use plugins instead
What is Power Fx and how is it used in Power Apps?
Power Fx:
→ Open-source, declarative formula language based on Excel-style syntax
→ Used in: Canvas Apps, Model-driven app command bars, Dataverse formulas
→ Reactive: formulas automatically recalculate when data changes
Key Power Fx patterns for PL-400:
Collections and local data:
// Create a collection:
ClearCollect(colProducts,
Filter(Products, Status.Value = "Active"))
// Add a record:
Collect(colProducts, {Name: "Widget", Price: 9.99})
// Update in collection:
UpdateIf(colProducts, ProductId = varSelectedId,
{Price: 12.99})
Delegation (CRITICAL concept):
→ Delegation = Dataverse handles the filter/sort on the server
→ Non-delegable = Power Apps downloads ALL records (max 2000) then filters
→ Always use delegable functions for large datasets
Delegable functions with Dataverse:
Filter(Products, Status.Value = "Active") ← DELEGABLE (server-filters)
Filter(Products, Text(Price) = "9.99") ← NOT DELEGABLE (Text() blocks delegation)
Workaround for non-delegable:
Set(varProducts, Filter(Products, Status.Value = "Active")) // 2000 limit
Filter(varProducts, Price > 5) // then filter collection client-side
Named formulas (performance):
// Named formula — evaluated once, cached:
ProductCount = CountRows(Filter(Products, Status = "Active"))
With() — local variables for readability:
With({total: Sum(OrderLines, Quantity * UnitPrice),
tax: Sum(OrderLines, Quantity * UnitPrice) * 0.20},
total + tax)
3. Extend the User Experience (10–15%)
What is the Power Apps Component Framework (PCF) and when do you use it?
PCF (Power Apps Component Framework):
→ Framework for building custom reusable UI components for Power Apps
→ Replaces HTML web resources for custom UI in model-driven apps
→ Available in: Model-driven apps AND canvas apps
→ Built with: TypeScript, React (optional), CSS, third-party libraries
Two types of PCF controls:
Field controls: replace a single field on a form
→ e.g., custom date picker, colour picker, rating stars, signature pad
Dataset controls: replace a grid/subgrid view
→ e.g., custom chart, calendar view, map view, Kanban board
PCF control lifecycle:
init(context, notifyOutputChanged, state, container):
→ Called once when control loads
→ Receive context (current field value, user info, client info)
→ Set up the component
updateView(context):
→ Called whenever field value OR model changes
→ Re-render the component with new data
getOutputs():
→ Called when notifyOutputChanged() is triggered
→ Return the new value to write back to Dataverse
destroy():
→ Called when control removed from DOM — cleanup
PCF TypeScript example (field control — custom star rating):
import { IInputs, IOutputs } from "./generated/ManifestTypes";
export class StarRating implements ComponentFramework.StandardControl<IInputs, IOutputs> {
private _value: number;
private _notifyOutputChanged: () => void;
private _container: HTMLDivElement;
init(context: ComponentFramework.Context<IInputs>,
notifyOutputChanged: () => void,
state: ComponentFramework.Dictionary,
container: HTMLDivElement): void {
this._notifyOutputChanged = notifyOutputChanged;
this._container = container;
this._value = context.parameters.rating.raw ?? 0;
this.renderStars();
}
updateView(context: ComponentFramework.Context<IInputs>): void {
this._value = context.parameters.rating.raw ?? 0;
this.renderStars();
}
getOutputs(): IOutputs {
return { rating: this._value };
}
private renderStars(): void {
this._container.innerHTML = '';
for (let i = 1; i <= 5; i++) {
const star = document.createElement('span');
star.textContent = i <= this._value ? '★' : '☆';
star.onclick = () => { this._value = i; this._notifyOutputChanged(); };
this._container.appendChild(star);
}
}
destroy(): void { /* cleanup */ }
}
PCF CLI commands:
pac pcf init --namespace Contoso --name StarRating --template field
npm install
npm run build
pac pcf push --publisher-prefix contoso # push to dev environment for testing
What are client-side scripts (JavaScript) in model-driven apps?
Client-side scripts (JavaScript) in model-driven apps:
→ Customise form behaviour without server-side code
→ Registered on: form events, field events, grid events, ribbon buttons
Key form events:
OnLoad: fires when form loads (initialise, set defaults, hide/show)
OnSave: fires when user saves (validate, prevent save, show warnings)
OnChange: fires when a specific field value changes
Xrm object model — the JavaScript API for model-driven apps:
// Get a field value:
const accountName = formContext.getAttribute("name").getValue();
// Set a field value:
formContext.getAttribute("creditlimit").setValue(50000);
// Show/hide a field:
formContext.getControl("telephone1").setVisible(false);
// Make a field required:
formContext.getAttribute("emailaddress1")
.setRequiredLevel("required");
// Display a form notification:
formContext.ui.setFormNotification(
"Credit limit exceeded!",
"WARNING", // INFO | WARNING | ERROR
"creditWarning"
);
// Prevent save with validation error:
function validateForm(executionContext) {
const formContext = executionContext.getFormContext();
const email = formContext.getAttribute("emailaddress1").getValue();
if (email && !email.includes("@")) {
executionContext.getEventArgs().preventDefault();
formContext.ui.setFormNotification(
"Invalid email address", "ERROR", "emailError");
}
}
// Call Dataverse Web API from client script:
Xrm.WebApi.retrieveMultipleRecords("account",
"?$select=name,creditlimit&$filter=statecode eq 0&$top=10")
.then(result => {
result.entities.forEach(account => {
console.log(account.name, account.creditlimit);
});
});
// Open a related record:
Xrm.Navigation.openForm({
entityName: "contact",
entityId: contactId
});
4. Extend the Platform — Plugins & APIs (40–45%)
What is a Dataverse Plugin and how does it work?
Dataverse Plugin:
→ C# class library that executes server-side business logic
→ Triggered by Dataverse events (create, update, delete, retrieve, etc.)
→ Runs within the Dataverse platform — no external hosting needed
→ Enforced regardless of HOW data is modified (Portal, API, App, import)
Plugin architecture:
public class AccountValidationPlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
// Get plugin execution context:
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
// Get organisation service for Dataverse operations:
var serviceFactory = (IOrganizationServiceFactory)
serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var service = serviceFactory.CreateOrganizationService(context.UserId);
// Get tracing service for logging:
var tracingService = (ITracingService)
serviceProvider.GetService(typeof(ITracingService));
// Only run on Account Create:
if (context.MessageName != "Create" ||
context.PrimaryEntityName != "account") return;
// Get the target entity (the record being created):
var target = (Entity)context.InputParameters["Target"];
// Business logic:
if (target.Contains("creditlimit") &&
target.GetAttributeValue<Money>("creditlimit").Value > 1000000)
{
throw new InvalidPluginExecutionException(
"Credit limit cannot exceed £1,000,000. Please contact Finance.");
}
tracingService.Trace("Account validation passed");
}
}
What are plugin pipeline stages and what happens in each?
Plugin execution pipeline (for each Dataverse message):
PRE-VALIDATION (stage 10):
→ Fires BEFORE the database transaction begins
→ Can query external systems without transaction overhead
→ Can prevent the operation with an exception
→ Use for: input validation, external system checks
→ No access to pre-entity image (record doesn't exist yet for Create)
PRE-OPERATION (stage 20):
→ Fires WITHIN the database transaction (BEFORE write to DB)
→ Can modify the Target entity before it's saved
→ Changes to Target automatically saved — no explicit update needed
→ Use for: set default field values, enrich the record before save
→ Pre-entity image: available for Update (the record as it was before)
MAIN OPERATION (stage 30):
→ The actual Dataverse platform operation (Core operation)
→ Cannot register custom plugins at this stage
→ Platform writes data to the database here
POST-OPERATION (stage 40):
→ Fires WITHIN the database transaction (AFTER write to DB)
→ Record is now in the database
→ Can trigger follow-on operations (create related records, send emails)
→ Post-entity image: available (record as it is now after save)
→ Changes require explicit service.Update() calls
→ Use for: creating related records, triggering workflows, notifications
Execution mode:
Synchronous: runs in the same thread as the user operation
failure rolls back the entire transaction
use for: validation, data enrichment (pre-operation)
Asynchronous: runs in background queue (separate thread)
failure does NOT roll back the user operation
use for: send emails, call external APIs, non-critical operations
Plugin images (snapshots of the record):
Pre-image: snapshot of the record BEFORE the operation
Post-image: snapshot of the record AFTER the operation
Both must be registered in Plugin Registration Tool (specify column names)
What are Custom Workflow Activities?
Custom Workflow Activities:
→ C# classes that extend Power Automate / Classic Workflows
→ Appear as steps that can be added in Power Automate (classic) or
used in low-code flows
→ Use when: need reusable server-side C# logic callable from flows
Structure:
public class CalculateDiscount : CodeActivity
{
// Input parameters from the flow:
[Input("Order Amount")]
[RequiredArgument]
public InArgument<decimal> OrderAmount { get; set; }
[Input("Customer Tier")]
public InArgument<string> CustomerTier { get; set; }
// Output parameters returned to the flow:
[Output("Discount Percentage")]
public OutArgument<decimal> DiscountPercentage { get; set; }
protected override void Execute(CodeActivityContext context)
{
var amount = OrderAmount.Get(context);
var tier = CustomerTier.Get(context) ?? "Standard";
decimal discount = tier switch {
"Gold" => amount > 10000 ? 0.15m : 0.10m,
"Silver" => 0.05m,
_ => 0m
};
DiscountPercentage.Set(context, discount);
}
}
Plugin vs Custom Workflow Activity:
Plugin: Triggered by Dataverse events (create/update/delete)
Custom Workflow Activity: Called from Power Automate or classic workflows
Reusable across multiple flows
User provides input, receives output
What is the Dataverse Web API and how do you use it?
Dataverse Web API:
→ RESTful OData v4 API for all Dataverse operations
→ Endpoint: https://{org}.api.crm11.dynamics.com/api/data/v9.2/
→ Authentication: OAuth 2.0 bearer token (Entra ID)
→ Available from: external apps, Azure Functions, Logic Apps, plugins
CRUD operations:
CREATE (POST):
POST /api/data/v9.2/accounts
Content-Type: application/json
{
"name": "Contoso Ltd",
"creditlimit": 50000,
"telephone1": "0207 123 4567",
"primarycontactid@odata.bind": "/contacts(00000000-0000-0000-0000-000000000001)"
}
Response: 201 Created + OData-EntityId header with new record GUID
READ (GET with OData):
GET /api/data/v9.2/accounts
?$select=name,creditlimit,telephone1
&$filter=creditlimit gt 10000 and statecode eq 0
&$orderby=name asc
&$top=50
&$expand=primarycontactid($select=fullname,emailaddress1)
UPDATE (PATCH — partial update):
PATCH /api/data/v9.2/accounts({accountId})
Content-Type: application/json
{
"creditlimit": 75000,
"telephone1": "0207 999 8888"
}
DELETE:
DELETE /api/data/v9.2/accounts({accountId})
Upsert (PATCH with If-None-Match: *):
PATCH /api/data/v9.2/accounts({alternateKey})
If-None-Match: * ← create if not exists, update if exists
{ ... }
Batch operations (multiple requests in one HTTP call):
POST /api/data/v9.2/$batch
Content-Type: multipart/mixed; boundary=batch_boundary
→ Reduces round trips for bulk operations
→ Supports change sets (atomic — all succeed or all fail)
Execute actions:
POST /api/data/v9.2/WinOpportunity
{
"OpportunityClose": {
"subject": "Won deal",
"opportunityid@odata.bind": "/opportunities({opportunityId})"
},
"Status": 3
}
5. Power Platform ALM & DevOps
What is Power Platform ALM and what are the key components?
ALM (Application Lifecycle Management) for Power Platform:
→ The practices and tools for managing the full lifecycle of Power Platform
solutions from development through test to production
Core ALM components:
Environments: Dev → Test/UAT → Production
Each environment is isolated with its own data
Solutions: the packaging unit — transport customisations between envs
Source control: Git repository stores solution source files
CI/CD pipelines: automate build, test, deploy using Azure DevOps or GitHub
Environment strategy (recommended):
Developer (individual): each developer has their own personal dev env
unmanaged solution, develop and unit test here
Test/QA: shared managed solution deployment, QA testing
UAT/Pre-prod: user acceptance testing with business users
Production: live environment — only managed solutions deployed
Key principles:
→ Never develop in Test or Production environments
→ Always deploy MANAGED solutions to non-dev environments
→ Every customisation lives inside a solution (nothing ungrouped)
→ Source control is the source of truth — not any environment
→ Automated deployment pipelines — no manual exports/imports
What is the Power Platform CLI and what can you do with it?
Power Platform CLI (pac CLI):
→ Command-line tool for Power Platform development and ALM
→ Install: dotnet tool install -g Microsoft.PowerApps.CLI
→ Or: via npm, VS Code extension, or Power Platform Tools installer
Key commands:
Authentication:
pac auth create --url https://org.crm.dynamics.com # add environment
pac auth list # list connections
pac auth select --index 1 # switch environment
Solution management:
pac solution list # list all solutions in env
pac solution export --path ./exported --name MySolution --managed false
pac solution import --path ./MySolution.zip
pac solution clone --name MySolution --outputDirectory ./src
# Clone: creates local folder structure with each component in separate file
Environment management:
pac env list # list environments
pac env select --environment "Dev Environment"
pac env create --name "My-Dev-Env" --type Developer --region unitedstates
PCF development:
pac pcf init --namespace Contoso --name MyControl --template field --run-npm-install
pac pcf push --publisher-prefix contoso # push to environment
pac pcf version --updateType patch # bump version
Plugin development:
pac plugin init # scaffold plugin project
pac plugin push # push assembly to env
Canvas app:
pac canvas pack --sources ./CanvasApp --msapp ./output/MyApp.msapp
pac canvas unpack --msapp ./MyApp.msapp --sources ./unpacked # for source control
Solution unpack (for source control — YAML format):
pac solution unpack --zipFile MySolution.zip --folder ./src --processCanvasApps
# Creates: Entities, Flows, Workflows, WebResources folders
# Each component in separate file → meaningful Git diffs
Solution pack (from source control → zip for deployment):
pac solution pack --zipFile MySolution_managed.zip --folder ./src --managed
How do you implement CI/CD for Power Platform with Azure DevOps?
Power Platform Build Tools (Azure DevOps):
→ Microsoft-provided extension: "Power Platform Build Tools"
→ Provides DevOps tasks for: export, import, publish, check solution
Complete CI/CD pipeline pattern:
CI Pipeline (Build) — triggered on PR to main branch:
1. Power Platform: Who Am I # validate connection
2. Power Platform: Export Solution # export unmanaged from Dev env
3. Power Platform: Unpack Solution # unpack to source files
4. Power Platform: Check Solution # run Solution Checker (code quality)
5. Power Platform: Pack Solution # pack as MANAGED for deployment
6. Publish Artifact # publish zip for release pipeline
CD Pipeline (Release) — triggered on merge to main:
Stage 1 — Deploy to Test:
Power Platform: Import Solution # import managed solution to Test
Power Platform: Publish Customizations
Run automated tests (EasyRepro / PAC test)
Stage 2 — Deploy to UAT (manual approval gate):
Approval required from business stakeholder
Power Platform: Import Solution # import managed to UAT
Stage 3 — Deploy to Production (manual approval):
Approval required from release manager
Power Platform: Import Solution # import managed to Production
Azure DevOps YAML pipeline example:
trigger:
branches:
include: [main]
pool:
vmImage: 'windows-latest'
steps:
- task: PowerPlatformToolInstaller@2
displayName: 'Install Power Platform Build Tools'
- task: PowerPlatformWhoAmi@2
displayName: 'Authenticate to Dev'
inputs:
authenticationType: 'PowerPlatformSPN'
PowerPlatformSPN: 'PP-Dev-SPN' # service connection
- task: PowerPlatformExportSolution@2
displayName: 'Export Solution'
inputs:
authenticationType: 'PowerPlatformSPN'
PowerPlatformSPN: 'PP-Dev-SPN'
SolutionName: 'ContosoSolution'
SolutionOutputFile: '$(Build.ArtifactStagingDirectory)/ContosoSolution.zip'
Managed: false
- task: PowerPlatformUnpackSolution@2
displayName: 'Unpack Solution'
inputs:
SolutionInputFile: '$(Build.ArtifactStagingDirectory)/ContosoSolution.zip'
SolutionTargetFolder: '$(Build.SourcesDirectory)/src/solution'
- task: PowerPlatformChecker@2
displayName: 'Solution Checker'
inputs:
authenticationType: 'PowerPlatformSPN'
PowerPlatformSPN: 'PP-Dev-SPN'
FilesToAnalyze: '$(Build.ArtifactStagingDirectory)/ContosoSolution.zip'
RuleSet: '0ad12346-e108-40b8-a956-9a373e9909ff' # AppSource ruleset
ErrorLevel: High
FailOnPowerAppsCheckerAnalysisError: true
What are Power Platform Pipelines (in-product ALM)?
Power Platform Pipelines (Fabric/Managed Pipelines):
→ Microsoft-native ALM solution BUILT INTO Power Platform (no Azure DevOps needed)
→ Configured entirely in the Power Platform Admin Centre / Pipelines app
→ Designed for: citizen developer ALM, simpler governance without DevOps expertise
Pipeline concepts:
Host environment: dedicated environment that hosts the pipeline configuration
+ deployment history + logs
Linked environments: Dev → Test → Production environments connected to the pipeline
Stage gates: manual approvals before deployment to each stage
Features:
→ One-click deployment from within the Maker experience (no DevOps knowledge needed)
→ Pre-deployment and post-deployment steps (run cloud flows)
→ Deployment notes and audit trail
→ Environment variable configuration per stage
→ Connection reference configuration per stage
→ Deployment history with rollback capability
When to use Pipelines vs Azure DevOps:
Power Platform Pipelines:
→ Simpler orgs, citizen developer-led ALM
→ No DevOps team or expertise
→ Quick setup, managed by Power Platform admins
→ Limited customisation and branching support
Azure DevOps / GitHub Actions:
→ Complex orgs, pro-dev teams
→ Need automated testing, branch strategies, complex approval gates
→ Full control over pipeline steps, scripts, and tooling
→ Integrates with broader DevOps ecosystem (work items, boards, repos)
6. Develop Integrations (5–10%)
What are Custom Connectors and how do you build one?
Custom Connector:
→ Wrapper around a REST or SOAP API that makes it usable in
Power Automate, Power Apps, and Logic Apps
→ Defined using OpenAPI (Swagger) specification
→ Supports: authentication (API key, OAuth 2.0, Basic, Windows)
Building a custom connector:
Step 1 — Define the API:
→ Import an existing OpenAPI (Swagger) .json or .yaml file
→ Or: enter Postman collection URL
→ Or: build manually in the custom connector wizard
Step 2 — Configure authentication:
No auth: public APIs, development
API key: pass key in header or query string
OAuth 2.0: full OAuth flow — user signs in to the external service
Generic OAuth: for non-standard OAuth flows
Step 3 — Define actions and triggers:
Action: user calls this to perform an operation (POST order, GET customer)
Trigger: external system notifies Power Automate of an event
Polling trigger: Power Automate polls your API every N seconds
Webhook trigger: external system sends event to Power Automate's webhook URL
Step 4 — Test and share:
→ Test each operation in the connector wizard
→ Share with specific users or the whole organisation
→ Submit to Microsoft AppSource for public listing (ISV scenario)
Custom connector policies (inline code transformations):
→ Policy templates: convert XML to JSON, set header, route request
→ Use for: API quirks without modifying the backend API
e.g., external API uses XML response — policy converts to JSON
external API URL changes per customer — route policy selects URL
Certification (certified connectors):
→ Submit to Microsoft for certification review
→ Certified connectors available to all Power Platform users
→ Requirements: public documentation, test accounts, SLA
What are Virtual Tables in Dataverse?
Virtual Tables (Virtual Entities):
→ Dataverse tables that map to EXTERNAL data sources
→ Data stays in the external system — Dataverse is a logical view
→ CRUD operations pass through to the external system in real time
→ Appear and behave like regular Dataverse tables (queries, forms, views)
How they work:
User opens a canvas app → retrieves Virtual Table records
→ Dataverse calls the Virtual Table Data Provider
→ Data Provider calls the external system (SQL, OData, REST API)
→ External system returns data → Dataverse returns to the user
→ No data copy, no sync, always live
Virtual Table providers:
OData v4 provider: built-in — connect to any OData v4 endpoint
Custom provider: C# plugin registered as a data provider
handles: retrieve, retrieve multiple, create, update, delete
Custom virtual table data provider (C#):
public class ExternalProductsPlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
var context = serviceProvider.GetService<IPluginExecutionContext>();
if (context.MessageName == "RetrieveMultiple")
{
// Call external API (e.g., legacy ERP system):
var products = CallERPSystemAPI();
// Convert to EntityCollection:
var entityCollection = new EntityCollection();
foreach (var product in products)
{
var entity = new Entity("contoso_product");
entity["contoso_name"] = product.Name;
entity["contoso_price"] = product.Price;
entityCollection.Entities.Add(entity);
}
context.OutputParameters["BusinessEntityCollection"] = entityCollection;
}
}
}
When to use virtual tables:
→ External data that must appear in Power Apps without ETL
→ Read-only reference data from a legacy system
→ Data too large to copy into Dataverse (compliance, licensing)
→ Real-time inventory, pricing from ERP — must not have sync lag
Limitations:
→ No offline access (requires live connection to external system)
→ No Dataverse-native features (rollup columns, duplicate detection)
→ Performance depends on external system response time
→ No audit history (Dataverse doesn't own the data)
7. Scenario-Based Questions
Scenario: A business rule is causing performance issues on a large Account table. How do you fix it?
Problem analysis:
→ Business rules with entity scope run server-side on every record operation
→ Complex business rules with many conditions slow down create/update operations
→ Business rules cannot be indexed or optimised by the database
Diagnosis steps:
1. Review business rules: Dataverse table → Business Rules → check scope
Entity-scoped rules run on every create/update from ANY source
2. Check if rule fires unnecessarily: is it checking conditions that
rarely change? e.g., checking account name on every address update
3. Profile with XrmToolBox → Plugin Trace Log: measure execution time
Solutions:
Option A — Convert to Pre-Operation Plugin (best performance):
→ Plugin only fires on specific messages you configure
→ Can check context.InputParameters to abort early if not relevant
→ Can use pre-image to only run if relevant fields actually changed:
var preImage = context.PreEntityImages["PreImage"];
var oldCreditLimit = preImage.GetAttributeValue<Money>("creditlimit")?.Value ?? 0;
var newCreditLimit = ((Entity)context.InputParameters["Target"])
.GetAttributeValue<Money>("creditlimit")?.Value ?? 0;
if (oldCreditLimit == newCreditLimit) return; // skip if not changed
Option B — Scope to Form only (not entity):
→ Changes business rule scope from Entity to Form
→ Rule only fires client-side when user is on the form
→ Not enforced for API/import operations — use only for UX enhancement
Option C — Replace with Calculated/Formula column:
→ If rule is setting a derived value, use a calculated column instead
→ Evaluated on read, not on write — zero write overhead
Scenario: Design a plugin that auto-creates a follow-up Task when an Opportunity is marked as Won.
public class OpportunityWonPlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
var serviceFactory = (IOrganizationServiceFactory)
serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var service = serviceFactory.CreateOrganizationService(context.UserId);
var tracingService = (ITracingService)
serviceProvider.GetService(typeof(ITracingService));
// Only on Opportunity Update:
if (context.MessageName != "Update" ||
context.PrimaryEntityName != "opportunity") return;
var target = (Entity)context.InputParameters["Target"];
// Only if statecode changed to Won (statecode = 1):
if (!target.Contains("statecode")) return;
var stateCode = target.GetAttributeValue<OptionSetValue>("statecode")?.Value;
if (stateCode != 1) return; // 1 = Won
// Get the Opportunity for owner details:
var opportunity = service.Retrieve("opportunity",
context.PrimaryEntityId,
new ColumnSet("name", "ownerid", "estimatedclosedate"));
tracingService.Trace($"Creating follow-up task for Won Opportunity: {opportunity["name"]}");
// Create a follow-up Task (async plugin — won't block the user):
var task = new Entity("task");
task["subject"] = $"Follow-up: {opportunity["name"]} - Won!";
task["description"] = "Send welcome pack and onboarding information";
task["regardingobjectid"] = new EntityReference("opportunity", context.PrimaryEntityId);
task["ownerid"] = opportunity["ownerid"]; // assign to opp owner
task["scheduledend"] = DateTime.UtcNow.AddDays(3); // due in 3 days
task["prioritycode"] = new OptionSetValue(2); // High priority
var taskId = service.Create(task);
tracingService.Trace($"Task created: {taskId}");
}
}
Plugin registration:
Entity: opportunity
Message: Update
Stage: Post-Operation (40) ← after save, record is in DB
Mode: Asynchronous ← non-blocking, failure won't rollback opp win
Images: none required (statecode is in Target)
Scenario: How do you implement a full ALM pipeline for a Power Platform solution from scratch?
Full ALM implementation steps:
1. Environment setup (Power Platform Admin Centre):
Developer environment: personal, each developer has their own
Test environment: shared, F-licence or Managed Environment
Production: Managed Environment, DLP policies enforced
2. Solution setup (Developer environment):
→ Create publisher: prefix "ctr", publisher name "Contoso"
→ Create solution: "ContosoSales" (associate with publisher)
→ ALL customisations inside this solution only
→ Set up Environment Variables for connection strings
→ Use Connection References for all flows
3. Azure DevOps setup:
→ Create repository: ContosoSales
→ Install "Power Platform Build Tools" extension from Marketplace
→ Create service connections (SPN):
PP-Dev-SPN: service principal with Maker role on Dev env
PP-Test-SPN: service principal with Maker role on Test env
PP-Prod-SPN: service principal with Maker role on Prod env
4. CI pipeline (builds/PRs):
→ Export solution (unmanaged) from Dev
→ Unpack to source files (pac solution unpack)
→ Run Solution Checker (fail on Critical errors)
→ Pack as Managed
→ Publish artifact (managed zip)
5. CD pipeline (deployments):
→ Import managed to Test (automatic)
→ Configure environment variables + connection references
→ Run smoke tests (EasyRepro UI tests or manual test checklist)
→ Approval gate: QA lead approves
→ Import managed to Production
→ Approval gate: Release manager approves
6. Developer daily workflow:
git checkout -b feature/TICKET-123-account-validation
# develop in personal dev environment
# export + unpack + commit
git push origin feature/TICKET-123-account-validation
# raise PR → CI pipeline runs → solution checker passes → peer review
# merge to main → CD pipeline deploys to Test
Scenario: A custom connector is failing authentication to a third-party API. How do you debug?
Systematic debugging approach:
Step 1 — Test the API directly (Postman or curl):
→ Call the API directly with the same credentials to confirm the API works
→ If direct call fails: the API itself has an issue (key expired, endpoint changed)
→ If direct call succeeds: the connector configuration is the issue
Step 2 — Check connector authentication configuration:
→ Power Automate → Custom Connectors → [connector] → Security tab
→ Verify: auth type, client ID, client secret, token URL, scopes
Step 3 — Check Power Automate run history:
→ Open failed flow run → expand the action → check error body
→ Common errors:
401 Unauthorized: wrong credentials, expired token, missing scope
403 Forbidden: correct auth but insufficient permissions
400 Bad Request: malformed request body — check connector definition
Step 4 — Test in connector wizard:
→ Custom Connectors → [connector] → Test tab
→ Create a new connection → test each operation individually
→ See raw request/response in test results
Step 5 — Check token refresh:
→ OAuth connectors: check if refresh token has expired (user must re-auth)
→ API key: check if key was rotated in the external system
→ Solution: update the connection in Power Automate with new credentials
Step 6 — Check environment variable / connection reference:
→ If connection reference used: verify the connection reference is configured
correctly in the target environment
→ Power Platform Admin Centre → Connections → verify active connections
8. Cheat Sheet — Quick Reference
PL-400 Exam Domain Priorities
Domain Weight Focus Areas
Extend the platform 40-45% C# plugins, Custom connectors,
Dataverse Web API, Virtual tables,
Power Platform CLI, ALM
Create a technical design 10-15% Low-code vs pro-code decision,
Architecture, Environment variables
Extend the user experience 10-15% PCF controls (TypeScript),
Client-side JavaScript (Xrm API)
Build Power Platform solutions 10-15% Solutions, Dataverse tables,
Power Fx, Delegation
Develop integrations 5-10% Custom connectors, Virtual tables,
Azure Functions, OData
Implement Power Apps improvements 5-10% Performance, delegation, formula optimisation
Plugin Pipeline Quick Reference
Stage When Use for Transaction
10 Pre- Before transaction External validation, No
Valid external system checks
20 Pre- In transaction, Set defaults, enrich Yes
Op before DB write record before save
30 Main The actual operation Not available for plugins Yes
40 Post- In transaction, Create related records, Yes
Op after DB write trigger integrations, notify
Execution modes:
Sync: blocks user, failure rolls back → use for validation
Async: background queue, failure does NOT roll back → use for notifications
Plugin images:
Pre-image (update/delete): record state BEFORE this operation
Post-image (create/update): record state AFTER this operation
Register in Plugin Registration Tool with specific column names
Dataverse Web API Quick Reference
Base URL: https://{org}.api.crm11.dynamics.com/api/data/v9.2/
OData operations:
GET /accounts?$select=name&$filter=... → retrieve multiple
GET /accounts({id}) → retrieve single
POST /accounts → create
PATCH /accounts({id}) → update (partial)
DELETE /accounts({id}) → delete
OData query options:
$select choose columns $select=name,creditlimit
$filter filter rows $filter=creditlimit gt 50000
$orderby sort $orderby=name asc
$top limit rows $top=100
$expand join related $expand=primarycontactid($select=fullname)
$count count results $count=true
Association:
POST /accounts({id})/contact_customer_accounts/$ref
{ "@odata.id": "/contacts({contactId})" }
Unbound action example:
POST /WinOpportunity
{ "OpportunityClose": {...}, "Status": 3 }
ALM Quick Reference
Solution types:
Unmanaged: development environment only — editable
Managed: non-dev environments — read-only, clean uninstall
Environment strategy:
Developer (personal) → Test (shared) → UAT → Production
Power Platform CLI key commands:
pac auth create --url {envUrl}
pac solution clone --name {solution}
pac solution pack --zipFile ./out.zip --managed
pac solution import --path ./out.zip
pac pcf init, push, version
pac canvas pack, unpack
Azure DevOps tasks:
PowerPlatformToolInstaller → install tools
PowerPlatformWhoAmi → validate connection
PowerPlatformExportSolution → export from source env
PowerPlatformUnpackSolution → unpack to source files
PowerPlatformChecker → run solution checker
PowerPlatformImportSolution → deploy to target env
PowerPlatformPublishCustomizations → publish after import
Pipeline pattern: Export → Unpack → Check → Pack → Import
PCF Control Lifecycle
Method When called Use for
init() Control loads (once) Setup, subscribe to events
updateView() Value or context changes Re-render the control
getOutputs() After notifyOutputChanged() Return new value to Dataverse
destroy() Control removed from DOM Cleanup, unsubscribe
Key context properties:
context.parameters.{fieldName}.raw → current field value
context.parameters.{fieldName}.formatted → formatted display value
context.userSettings.userName → current user name
context.client.isOffline → offline mode?
context.mode.isControlDisabled → read-only?
context.factory.requestRender() → request re-render
Top 10 Tips
-
Extend the platform = 40–45% of PL-400 — this single domain is almost half the exam. Master: C# plugins (all pipeline stages), Dataverse Web API (OData), custom connectors, Power Platform CLI, and ALM. Everything else is secondary to this domain.
-
Plugin stage selection is heavily tested — Pre-Operation (stage 20) to modify the Target before save (no explicit Update needed). Post-Operation (stage 40) to create related records (explicit Update needed). Pre-Validation (stage 10) for external system checks without a transaction. Know which stage to use for which scenario.
-
Sync vs Async plugins = validation vs notification — synchronous plugins block the user and roll back on failure (use for validation). Asynchronous plugins run in background and don't roll back the triggering operation (use for sending emails, calling external APIs).
-
Always try low-code first — the exam tests your ability to decide when pro-code is justified. If a Business Rule or Power Automate flow can solve the problem, that's the right answer. Only escalate to plugins when genuinely needed.
-
Connection references and environment variables are the ALM foundation — flows must use Connection References (not direct connections) and variables must use Environment Variables (not hardcoded values). Without these, solutions break when moved between environments.
-
pac solution unpack enables meaningful Git diffs — without unpacking, a solution is a binary ZIP file that can't be diff'd or reviewed. Unpacking creates YAML/XML files per component — pull requests show exactly what changed.
-
PCF controls replace HTML web resources — HTML web resources are legacy. PCF controls are the modern extension point for custom UI, with proper TypeScript support, lifecycle management, and canvas app compatibility.
-
Virtual tables = no data copy, always live — data stays in the external system and Dataverse proxies queries through. No sync lag, no duplication, but no offline access and no Dataverse-native features (rollup columns, duplicate detection).
-
Power Platform Pipelines vs Azure DevOps — Pipelines for simpler orgs and citizen developer ALM (built into Power Platform, no DevOps expertise needed). Azure DevOps for complex orgs needing branch strategies, automated testing, and full DevOps integration.
-
Solution Checker is mandatory before production — Solution Checker (run via Azure DevOps task or pac solution check) detects performance and reliability issues in plugins, JavaScript, and flows. Failing on Critical issues as a pipeline gate is the enterprise best practice for preventing broken deployments.
No comments:
Post a Comment