Microsoft Dataverse Advanced — Complete Guide
Plugins · PCF Controls · Web API · Business Rules · Security · Performance · ALM · Scenarios · Cheat Sheet
Table of Contents
- Core Concepts — Advanced Dataverse
- Plugins — Deep Dive
- PCF Controls — Deep Dive
- Dataverse Web API
- Business Logic & Automation
- Security & ALM
- Scenario-Based Questions
- Cheat Sheet — Quick Reference
1. Core Concepts — Advanced Dataverse
What is Microsoft Dataverse and what makes it enterprise-grade?
Microsoft Dataverse is the cloud-based data platform underpinning the entire Power Platform and Dynamics 365. It provides a structured, governed data store with built-in business logic, security, and extensibility.
What makes Dataverse enterprise-grade:
Relational data model:
→ Tables (entities), Columns (attributes), Relationships
→ Standard tables: Account, Contact, Lead, Opportunity, Case, etc.
→ Custom tables: create your own business-specific tables
→ Virtual tables: surface external data as Dataverse tables (no copy)
Business logic layers:
→ Column-level: data type, format, required, default value
→ Business rules: no-code field validation and show/hide logic
→ Plugins: C# server-side event handlers (full .NET access)
→ Custom APIs: define your own messages and operations
→ Workflows (deprecated) / Power Automate: process automation
Security model:
→ Role-based: security roles define table/column/record access
→ Business units: hierarchical org structure for data isolation
→ Field security profiles: restrict specific column access
→ Row-level security: owner, sharing, team-based record access
Platform services:
→ Audit logging: track every record change
→ Duplicate detection: prevent duplicate records
→ Change tracking: delta sync for external integration
→ File/Image columns: native binary storage
→ Calculated/Rollup columns: formula-based values
What is the Dataverse event pipeline?
The event pipeline is the ordered sequence in which Dataverse processes operations. Understanding it is essential for plugin and custom API development.
Dataverse Event Pipeline (for synchronous plugins):
1. Pre-Validation stage (Stage 10):
→ Runs BEFORE input validation
→ Outside the database transaction
→ Can stop the operation before it begins
→ Use for: permission checks, prerequisite validation
→ Rollback: NOT rolled back if later steps fail
2. Pre-Operation stage (Stage 20):
→ Runs AFTER input validation, BEFORE database write
→ Inside the database transaction
→ Target entity in context: BEFORE values (can modify Target)
→ Use for: default values, data enrichment, pre-write validation
→ Rollback: YES — rolled back if main operation fails
3. Main Operation:
→ The actual database write (Create/Update/Delete/etc.)
→ Dataverse performs the core operation
4. Post-Operation stage (Stage 40):
→ Runs AFTER database write
→ Inside the database transaction (synchronous)
→ Target entity has the AFTER values (incl. new record ID)
→ Use for: related record creation, notifications, downstream updates
→ Rollback: YES (synchronous) / NO (asynchronous)
Synchronous vs Asynchronous:
Synchronous: executes inline, user waits, part of transaction
Asynchronous: queued for later execution, user continues, NOT in transaction
Pre-Image vs Post-Image:
Pre-Image: snapshot of record BEFORE the operation (registered separately)
Post-Image: snapshot of record AFTER the operation (registered separately)
Use: compare old vs new values in Update plugins
What are Custom APIs in Dataverse?
Custom APIs allow you to define your own messages (operations) in Dataverse — creating reusable, callable actions that can be invoked from Power Automate, Power Apps, PCF, Web API, or Copilot Studio.
Custom API vs Custom Actions (deprecated approach):
Custom Actions (older): defined in solution, limited capabilities
Custom API (modern): richer definition, request/response params,
plugin association, discoverable via metadata
Custom API components:
Name: unique message name (e.g., contoso_CalculateDiscount)
Binding type: Global (no entity) / Entity / Entity Collection
Request params: input parameters (string, int, entity, etc.)
Response props: output values returned to caller
Plugin type: optional C# plugin implementing the logic
Enabled for: Workflow / Power Automate / Plug-in Step / Custom Processing
Calling Custom API:
// Web API:
POST https://contoso.crm.dynamics.com/api/data/v9.2/contoso_CalculateDiscount
{
"OrderAmount": 5000,
"CustomerTier": "Gold"
}
// Power Automate:
Action: "Perform an unbound action" OR "Perform a bound action"
→ Select custom API from action dropdown
// C# SDK:
var request = new OrganizationRequest("contoso_CalculateDiscount");
request["OrderAmount"] = 5000m;
request["CustomerTier"] = "Gold";
var response = service.Execute(request);
decimal discount = (decimal)response["DiscountPercentage"];
2. Plugins — Deep Dive
What is a Dataverse Plugin and what can it do?
A Dataverse Plugin is a C# class implementing IPlugin that executes server-side business logic in response to Dataverse events (Create, Update, Delete, Retrieve, Associate, custom messages).
using Microsoft.Xrm.Sdk;
using System;
public class AccountPostCreatePlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
// 1. Get services from the service provider
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
var serviceFactory = (IOrganizationServiceFactory)
serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var tracingService = (ITracingService)
serviceProvider.GetService(typeof(ITracingService));
// 2. Validate context — defensive programming
if (context.InputParameters.Contains("Target") &&
context.InputParameters["Target"] is Entity)
{
var target = (Entity)context.InputParameters["Target"];
// 3. Validate entity type
if (target.LogicalName != "account")
return;
try
{
tracingService.Trace("AccountPostCreatePlugin: starting");
// 4. Get the Org service (running as system or calling user)
var service = serviceFactory
.CreateOrganizationService(context.UserId);
// 5. Business logic — create a default Contact for new Account
var defaultContact = new Entity("contact");
defaultContact["firstname"] = "Primary";
defaultContact["lastname"] = "Contact";
defaultContact["parentcustomerid"] =
new EntityReference("account", target.Id);
service.Create(defaultContact);
tracingService.Trace("Default contact created successfully");
}
catch (Exception ex)
{
throw new InvalidPluginExecutionException(
$"AccountPostCreatePlugin failed: {ex.Message}", ex);
}
}
}
}
What are the key Plugin Registration settings?
Plugin Registration Tool (PRT) settings:
Message: Dataverse operation that triggers the plugin
Common: Create, Update, Delete, Retrieve, RetrieveMultiple,
Associate, Disassociate, Assign, SetState, Merge,
GrantAccess, ModifyAccess, RevokeAccess
Primary Entity: which table the message applies to
e.g., account, contact, incident, custom_table
Stage: when in the pipeline the plugin runs
10 = Pre-Validation (outside transaction)
20 = Pre-Operation (inside transaction, before write)
40 = Post-Operation (inside transaction for sync,
outside for async)
Execution Mode:
Synchronous: runs inline, user waits, in transaction
Asynchronous: queued, user continues, out of transaction
Filtering Attributes (for Update):
Specify which columns trigger the plugin
e.g., only trigger when "revenue" or "accountcategorycode" changes
Without filtering: plugin fires on ANY field update (expensive!)
Rank: order of execution when multiple plugins on same message/stage
Lower rank = executes first (rank 1 before rank 2)
Secure/Unsecure Configuration:
Config strings passed to plugin constructor at registration
Secure: encrypted, only visible to admins
Unsecure: visible in solution, use for non-sensitive config
Images:
Pre-Image: snapshot before the operation (register separately)
Post-Image: snapshot after the operation
Use: compare old vs new values in Update plugins
What are best practices for Plugin development?
1. Always check context defensively:
if (!context.InputParameters.Contains("Target")) return;
if (context.MessageName != "Create") return;
if (context.PrimaryEntityName != "account") return;
2. Use Filtering Attributes on Update:
Register with specific columns — don't fire on every field update
"revenue,accountcategorycode,primarycontactid"
3. Never use heavyweight operations in Pre-Validation:
Pre-Validation is outside transaction → expensive operations waste time
Move heavyweight logic to Post-Operation async
4. Use Tracing extensively:
tracingService.Trace("Entering: {0}", nameof(MyPlugin));
tracingService.Trace("Target ID: {0}", target.Id);
// Trace logs appear in plugin execution exception details
// Essential for debugging — plugins have no debugger in prod
5. Throw InvalidPluginExecutionException for business errors:
throw new InvalidPluginExecutionException(
"Cannot close case: missing resolution description");
// Shows as user-friendly error in the UI
6. Never query all columns — use ColumnSet:
var account = service.Retrieve("account", accountId,
new ColumnSet("name", "revenue", "primarycontactid"));
// NOT: new ColumnSet(true) — fetches all columns (expensive)
7. Avoid N+1 queries — use RetrieveMultiple with FetchXML:
var query = new FetchExpression("<fetch>...</fetch>");
var results = service.RetrieveMultiple(query);
// NOT: loop + individual Retrieve calls
8. Plugin Depth limit:
Context.Depth tracks recursive calls
if (context.Depth > 1) return; // Prevent infinite loops
// Plugin A creates record → Plugin B fires → loops back to A
9. Use Dependency Injection for testability:
Constructor injection: pass IOrganizationService for unit testing
Avoid direct new() instantiation of service objects
10. Register in Solutions for ALM:
Use Plugin Registration Tool to register steps as solution components
Never register directly to production — always promote via solution
What is Plugin Profiler and how do you debug plugins?
Local debugging with Plugin Profiler:
1. Install Plugin Registration Tool (PRT)
2. In PRT: Install Profiler → deploys profiler plugin to environment
3. Select your plugin step → "Start Profiling"
4. Execute the operation in the app (triggers plugin)
5. Profiler captures: execution context snapshot to clipboard/file
6. In Visual Studio: attach debugger to "PluginRegistration.exe"
7. PRT: Replay Profile → loads context into local plugin execution
8. Breakpoints hit in Visual Studio → debug with real production data
Tracing for production debugging:
tracingService.Trace("Processing account: {0}", accountId);
→ Trace appears in: Plugin Execution Exception detail
→ Enable plugin trace logs: Settings → Administration →
System Settings → Customization → Enable logging to plug-in trace log
→ View traces: Settings → Plug-in Trace Log
Unit testing plugins:
// Mock IOrganizationService using Moq:
var mockService = new Mock<IOrganizationService>();
mockService.Setup(s => s.Retrieve("account", It.IsAny<Guid>(),
It.IsAny<ColumnSet>()))
.Returns(new Entity("account") { Id = Guid.NewGuid() });
var plugin = new MyPlugin(mockService.Object);
// Test plugin logic without Dataverse connection
3. PCF Controls — Deep Dive
What is a PCF Control and when do you use one?
PCF (PowerApps Component Framework) controls are custom UI components built with TypeScript/JavaScript that replace or augment the standard fields and views in model-driven apps, canvas apps, and Power Pages.
When to use PCF:
→ Standard Dataverse controls don't meet UX requirements
→ Need third-party library integration (charts, maps, editors)
→ Complex inline editing or validation logic
→ Custom visualisation of data (progress bars, star ratings, etc.)
→ Reusable branded UI components across multiple apps
PCF control types:
Field control:
→ Replaces the rendering of a single field on a form
→ Gets/sets the column value
→ Examples: colour picker, rich text editor, star rating,
formatted phone number display
Dataset control:
→ Replaces an entire subgrid or view (list of records)
→ Gets the collection of records from the dataset
→ Examples: custom calendar view, Kanban board,
map view of address records, custom grid
PCF vs Canvas App component:
PCF: TypeScript + React/vanilla JS, compiled, runs natively
Canvas comp: Power Fx + Power Apps controls, low-code, easier
Use PCF: complex rendering, performance-critical, third-party libs
Use canvas: maker-level complexity, simple reusable components
What is the PCF Control lifecycle?
// PCF Control implementing StandardControl interface
import { IInputs, IOutputs } from "./generated/ManifestTypes";
export class StarRatingControl
implements ComponentFramework.StandardControl<IInputs, IOutputs> {
private _container: HTMLDivElement;
private _context: ComponentFramework.Context<IInputs>;
private _notifyOutputChanged: () => void;
private _currentRating: number;
// init: called ONCE when control is loaded
public init(
context: ComponentFramework.Context<IInputs>,
notifyOutputChanged: () => void,
state: ComponentFramework.Dictionary,
container: HTMLDivElement
): void {
this._context = context;
this._notifyOutputChanged = notifyOutputChanged;
this._container = container;
// Get initial value from bound column
this._currentRating = context.parameters.rating.raw ?? 0;
// Render initial UI
this.renderControl();
}
// updateView: called when bound column value changes externally
// OR when form refreshes
public updateView(
context: ComponentFramework.Context<IInputs>
): void {
this._context = context;
// Check if value changed from outside
if (context.parameters.rating.raw !== this._currentRating) {
this._currentRating = context.parameters.rating.raw ?? 0;
this.renderControl();
}
}
// getOutputs: called when notifyOutputChanged() was called
// Returns new values to write back to bound column
public getOutputs(): IOutputs {
return {
rating: this._currentRating
};
}
// destroy: called when control is removed from DOM
public destroy(): void {
// Clean up event listeners, third-party libraries
this._container.innerHTML = "";
}
private renderControl(): void {
this._container.innerHTML = "";
for (let i = 1; i <= 5; i++) {
const star = document.createElement("span");
star.textContent = i <= this._currentRating ? "★" : "☆";
star.style.cursor = "pointer";
star.style.fontSize = "24px";
star.addEventListener("click", () => {
this._currentRating = i;
this._notifyOutputChanged(); // tells PCF: value changed
this.renderControl();
});
this._container.appendChild(star);
}
}
}
What is the PCF manifest file?
<!-- ControlManifest.Input.xml — defines the control's contract -->
<?xml version="1.0" encoding="utf-8" ?>
<manifest>
<control namespace="Contoso.Controls" constructor="StarRatingControl"
version="1.0.0" display-name-key="StarRating_Display_Key"
description-key="StarRating_Desc_Key" control-type="standard">
<!-- Property: binding to a Dataverse column -->
<property name="rating"
display-name-key="Rating_Display_Key"
description-key="Rating_Desc_Key"
of-type="Whole.None"
usage="bound"
required="true" />
<!-- Input-only property: configuration value -->
<property name="maxStars"
display-name-key="MaxStars_Display_Key"
of-type="Whole.None"
usage="input"
required="false" />
<!-- Resources: JS bundle and CSS -->
<resources>
<code path="index.ts" order="1" />
<css path="css/StarRating.css" order="1" />
</resources>
<!-- Feature usage: declares needed platform features -->
<feature-usage>
<uses-feature name="Device.captureAudio" required="false" />
<uses-feature name="WebAPI" required="false" />
</feature-usage>
</control>
</manifest>
What are PCF WebAPI and Navigation capabilities?
// PCF provides context.webAPI for Dataverse operations:
public async init(context, notifyOutputChanged, state, container) {
// CREATE a record:
const result = await context.webAPI.createRecord("account", {
name: "Contoso Ltd",
revenue: 1000000
});
console.log("Created account ID:", result.id);
// RETRIEVE a record:
const account = await context.webAPI.retrieveRecord(
"account",
accountId,
"?$select=name,revenue,primarycontactid"
);
// RETRIEVE MULTIPLE (with OData filter):
const accounts = await context.webAPI.retrieveMultipleRecords(
"account",
"?$select=name,revenue&$filter=revenue gt 100000&$top=10"
);
accounts.entities.forEach(a => console.log(a.name));
// UPDATE a record:
await context.webAPI.updateRecord("account", accountId, {
revenue: 2000000
});
// DELETE a record:
await context.webAPI.deleteRecord("account", accountId);
}
// Navigation: open forms, URLs:
// Open a record form:
context.navigation.openForm({
entityName: "account",
entityId: accountId
});
// Open a URL in a dialog:
context.navigation.openUrl("https://contoso.com");
// Device capabilities:
// Take photo (mobile):
const image = await context.device.captureImage({ allowEdit: true });
PCF Build and Deployment
# Prerequisites: Node.js, Power Platform CLI, VS Code
# Create new PCF project:
pac pcf init --namespace Contoso.Controls --name StarRatingControl --template field
# Install dependencies:
npm install
# Build (TypeScript compilation):
npm run build
# Start test harness (hot reload in browser):
npm start
# Build for production:
npm run build -- --mode production
# Push to Dataverse environment directly (dev only):
pac pcf push --publisher-prefix contosodev
# Package in solution for ALM deployment:
# 1. Create solution project:
pac solution init --publisher-name Contoso --publisher-prefix contoso
# 2. Add PCF reference to solution:
pac solution add-reference --path ../StarRatingControl
# 3. Build solution:
dotnet build
# 4. Deploy managed solution:
pac solution import --path ./bin/Release/Solution.zip
4. Dataverse Web API
What is the Dataverse Web API and how is it structured?
Dataverse Web API:
→ RESTful OData v4 API for all Dataverse operations
→ Base URL: https://{org}.crm.dynamics.com/api/data/v9.2/
→ Authentication: OAuth 2.0 Bearer token (Entra ID)
→ Content-Type: application/json
CRUD operations:
CREATE (POST):
POST /api/data/v9.2/accounts
{
"name": "Contoso Ltd",
"revenue": 1000000,
"primarycontactid@odata.bind": "/contacts(guid)"
}
Returns: 204 No Content, OData-EntityId header = new record URL
RETRIEVE (GET):
GET /api/data/v9.2/accounts(guid)?$select=name,revenue
GET /api/data/v9.2/accounts?$select=name&$filter=revenue gt 500000&$top=10
UPDATE (PATCH):
PATCH /api/data/v9.2/accounts(guid)
{ "revenue": 2000000 }
Returns: 204 No Content
DELETE (DELETE):
DELETE /api/data/v9.2/accounts(guid)
Returns: 204 No Content
UPSERT (PATCH with If-None-Match):
PATCH /api/data/v9.2/accounts(guid)
If-Match: * → update only (fail if not exists)
If-None-Match: * → create only (fail if exists)
(no header) → upsert: create if not exists, update if exists
What are the key OData query options in the Dataverse Web API?
$select — specify columns to return:
GET /accounts?$select=name,revenue,statecode
$filter — filter records:
GET /accounts?$filter=revenue gt 1000000
GET /accounts?$filter=statecode eq 0 and contains(name,'Contoso')
GET /contacts?$filter=parentcustomerid/accountid eq {guid}
$orderby — sort results:
GET /accounts?$orderby=revenue desc,name asc
$top — limit results:
GET /accounts?$top=50
$skip — pagination offset:
GET /accounts?$top=10&$skip=20 ← page 3
$expand — include related entity inline:
GET /accounts?$expand=primarycontactid($select=fullname,emailaddress1)
GET /incidents?$expand=customerid_account($select=name,revenue)
$count — include total count:
GET /accounts?$count=true
$apply — aggregations (OData aggregation):
GET /opportunities?$apply=aggregate(estimatedvalue with sum as TotalValue)
Lookup / EntityReference filter:
GET /incidents?$filter=customerid_account/accountid eq {guid}
GET /contacts?$filter=_parentcustomerid_value eq {guid}
Alternative key (e.g., by email):
GET /contacts(emailaddress1='alice@contoso.com')
How do you execute Custom APIs and Functions via Web API?
Unbound functions (no specific record):
GET /api/data/v9.2/WhoAmI()
Response: { "UserId": "guid", "BusinessUnitId": "guid", "OrganizationId": "guid" }
GET /api/data/v9.2/RetrieveVersion()
Response: { "Version": "9.2.24031.00140" }
Bound function (on a specific record):
GET /api/data/v9.2/accounts(guid)/Microsoft.Dynamics.CRM.RetrievePrincipalAccess
(Target=@target)?@target={"@odata.id":"accounts(guid)"}
Unbound actions:
POST /api/data/v9.2/SendEmail
{ "EmailId": "guid", "IssueSend": true }
Custom API (unbound action):
POST /api/data/v9.2/contoso_CalculateDiscount
{
"OrderAmount": 5000,
"CustomerTier": "Gold"
}
Response: { "DiscountPercentage": 15.0 }
Custom API (bound to entity):
POST /api/data/v9.2/accounts(guid)/Microsoft.Dynamics.CRM.contoso_ApproveAccount
{}
Batch requests ($batch):
POST /api/data/v9.2/$batch
Content-Type: multipart/mixed;boundary=batch_boundary
--batch_boundary
Content-Type: multipart/mixed;boundary=changeset_boundary
--changeset_boundary
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /api/data/v9.2/accounts HTTP/1.1
Content-Type: application/json
{ "name": "Contoso Ltd" }
--changeset_boundary--
--batch_boundary--
What is Change Tracking in the Dataverse Web API?
Change tracking enables delta sync — retrieve only records
changed since the last sync, without fetching everything.
Enable change tracking:
→ Table Settings → "Change Tracking" = On
→ Required for delta sync and Dataverse integration patterns
Initial full sync:
GET /api/data/v9.2/accounts?$select=name,revenue
Response headers:
Preference-Applied: odata.track-changes
OData-DeltaLink: /api/data/v9.2/accounts?$deltatoken=xyz123
Store the DeltaLink token.
Incremental sync (only changes since last token):
GET /api/data/v9.2/accounts?$deltatoken=xyz123
Response:
{
"value": [
{ "accountid": "guid1", "name": "Updated Name" }, // updated
{ "accountid": "guid2", "@removed": { "reason": "deleted" } } // deleted
],
"@odata.deltaLink": "...?$deltatoken=abc456" // new token
}
Store new deltaLink for next sync.
Use cases:
→ Sync Dataverse data to external data warehouse
→ Trigger downstream processes on record changes
→ Replicate to Azure SQL or Fabric via ADF / Logic Apps
→ Mobile app offline sync (sync changes when reconnected)
5. Business Logic & Automation
What are Business Rules in Dataverse and what can they do?
Business Rules: no-code/low-code logic attached to a table
Applied: client-side (model-driven forms) and/or server-side
Business Rule capabilities:
→ Show/Hide fields: conditionally show/hide columns
→ Enable/Disable fields: make fields read-only conditionally
→ Set field value: pre-populate or calculate field value
→ Set required/not required: dynamic required fields
→ Set default value: set a column's default on new records
→ Validate data: show error message when condition is met
→ Recommend value: suggest a value (user can override)
Scope options:
Entity: server-side — applies to ALL interfaces (forms, API, plugin)
All Forms: client-side — applies to all forms in the app
Specific Form: client-side — applies to one specific form only
Example Business Rule:
IF Status = "On Hold" AND HoldReason is empty
THEN:
Show error: "Please provide a Hold Reason"
Set HoldReason = required
Best practices:
→ Use Entity scope for validation that should ALWAYS apply
→ Use Form scope for UX-only changes (show/hide)
→ Avoid complex multi-condition rules — use plugins instead
→ Test: rules with Entity scope fire via API too — test both UI and API
Limitations:
→ Cannot query related records (no lookups across tables)
→ Cannot call external services
→ Cannot create/update other records
→ For complex logic: use plugins or Power Automate
What are Dataverse Calculated and Rollup columns?
Calculated Columns:
→ Value computed from formula at retrieval time
→ No stored value — calculated each time the record is fetched
→ Formula types: date/time arithmetic, string concatenation,
numeric calculations, conditional (if/else)
Examples:
FullName = FirstName + " " + LastName
DaysUntilExpiry = DaysFromToday(ExpiryDate)
AnnualRevenue_USD = Revenue * ExchangeRate
Priority_Label = IF(Priority = 1, "High", IF(Priority = 2, "Medium", "Low"))
Limitations:
→ Cannot reference related table columns directly in formula
→ Cannot be used in Power Automate filter conditions efficiently
→ Not stored → cannot index for query performance
Rollup Columns:
→ Aggregation over related child records
→ Calculated on a schedule (every 12 hours default, manual trigger available)
→ Result stored in the parent record
Examples:
Account.TotalOpportunityValue = SUM(Opportunity.EstimatedValue)
WHERE Opportunity.StatusCode = Open
Account.NumberOfCases = COUNT(Case.CaseId)
WHERE Case.StateCode = Active
Contact.LastInteractionDate = MAX(Activity.ActualEnd)
Performance note:
→ Rollup columns are stored — efficient to query and index
→ 12-hour refresh lag — not suitable for real-time dashboards
→ Trigger immediate recalculation: CalculateRollupField message
What are Virtual Tables in Dataverse?
Virtual Tables (Virtual Entities):
→ Tables that appear in Dataverse but data lives in an external source
→ No data duplication — queries passed through to external system
→ Appear to apps, Power Automate, and API consumers as native tables
How they work:
1. Register a Data Provider plugin (custom C# code)
2. Plugin receives Retrieve/RetrieveMultiple requests
3. Plugin queries the external system (REST API, SQL, SAP)
4. Plugin returns results as Entity collection
5. Dataverse returns results as if they were native records
Use cases:
→ Read data from SAP without replicating to Dataverse
→ Surface Azure SQL data in model-driven apps
→ Integrate external REST API data as a Dataverse table
→ Display SharePoint list data in a model-driven subgrid
Limitations:
→ No native create/update/delete (unless provider implements it)
→ No offline capability
→ No relationships with standard Dataverse tables (limited)
→ No Dataverse search indexing
→ No audit logging
→ Performance depends on the external system
Virtual connector providers (out-of-box):
→ SharePoint connector provider (virtual SharePoint tables)
→ SQL Server provider
→ Excel Online provider
6. Security & ALM
What is the Dataverse security model in depth?
Security layers:
1. Authentication: Entra ID OAuth — who can access the environment
2. Licensing: user must have appropriate Power Apps or D365 licence
3. Security Roles (what operations on which tables):
Each role has privileges for each table:
Privilege levels:
None (0): no access
User (1): own records only
Business Unit (2): records in user's BU + sub-BUs
Parent BU (3): user's BU + parent BUs (rarely used)
Organisation (4): ALL records in the tenant
Operations per table:
Create, Read, Write, Delete, Append, AppendTo, Assign, Share
Column Security Profiles (field-level security):
→ Restrict Read/Update/Create of specific columns
→ Apply to: Social Security Number, Salary, sensitive fields
→ Overrides security role access for those columns
→ Assign profiles to users or teams
4. Business Units (org hierarchy for data isolation):
Root BU → Regional BU → Departmental BU
Users in a BU inherit access to records in their BU's scope
Move user to different BU = changes their data access scope
5. Record sharing (extending access beyond roles):
→ Share a specific record with a user/team
→ Grants access beyond what their security role allows
→ Use sparingly — creates complex access patterns
→ Prefer: reassign to shared team instead
6. Teams:
Owner team: can own records (records assigned to team)
Access team: shares access to specific records (no ownership)
Entra ID group team: membership managed via Entra ID group
What are Dataverse ALM best practices?
Solution types:
Unmanaged solution:
→ Development environment ONLY
→ Fully editable, no restrictions
→ Components can be modified or deleted
Managed solution:
→ Target environments (Test, UAT, Production)
→ Read-only — cannot edit managed components
→ Uninstall = removes all managed components (clean)
→ Layering: multiple managed solutions can coexist
Solution layering:
Base solution (ISV or Microsoft base)
→ Customisation layer 1 (your org solution)
→ Customisation layer 2 (environment-specific patches)
Active layer: what the environment actually uses
ALM workflow:
Dev environment:
→ Develop in unmanaged solution
→ pac solution export --managed (creates managed zip)
CI/CD pipeline:
→ pac solution export → Git commit
→ PR review → merge
→ pac solution import to Test → UAT → Production
Solution segmentation:
→ Separate solutions by domain: CRM, Finance, HR
→ Core solution: shared base (tables, security roles)
→ Feature solutions: depend on core, add features
→ Reduces merge conflicts, enables independent deployment
Environment variables:
→ Use for config that differs between environments
→ API endpoints, SharePoint URLs, email addresses
→ Set per-environment without solution change
→ Types: String, Number, Boolean, JSON, Secret (Key Vault)
7. Scenario-Based Questions
Scenario: Prevent duplicate account creation based on phone number.
Approach: Pre-Operation plugin on Account Create
public class AccountPreCreateDuplicateCheck : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
var factory = (IOrganizationServiceFactory)
serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var tracing = (ITracingService)
serviceProvider.GetService(typeof(ITracingService));
if (context.MessageName != "Create" ||
context.PrimaryEntityName != "account") return;
var target = (Entity)context.InputParameters["Target"];
if (!target.Contains("telephone1")) return;
var phone = target.GetAttributeValue<string>("telephone1");
if (string.IsNullOrWhiteSpace(phone)) return;
var service = factory.CreateOrganizationService(context.UserId);
// Query for existing accounts with same phone
var query = new QueryExpression("account")
{
ColumnSet = new ColumnSet("accountid", "name"),
TopCount = 1
};
query.Criteria.AddCondition("telephone1",
ConditionOperator.Equal, phone);
query.Criteria.AddCondition("statecode",
ConditionOperator.Equal, 0); // Active only
var results = service.RetrieveMultiple(query);
if (results.Entities.Count > 0)
{
var existing = results.Entities[0];
throw new InvalidPluginExecutionException(
$"An active account with phone {phone} already exists: " +
$"'{existing["name"]}'. Please use the existing account.");
}
}
}
Registration: Message=Create, Entity=account, Stage=Pre-Operation (20), Mode=Synchronous
Scenario: Design a PCF control that displays a progress bar for opportunity probability.
// ProgressBarControl.ts
export class ProgressBarControl
implements ComponentFramework.StandardControl<IInputs, IOutputs> {
private _container: HTMLDivElement;
private _bar: HTMLDivElement;
private _label: HTMLSpanElement;
public init(context, notifyOutputChanged, state, container): void {
this._container = container;
// Create wrapper
const wrapper = document.createElement("div");
wrapper.style.cssText = "display:flex;align-items:center;gap:8px;width:100%";
// Create progress bar track
const track = document.createElement("div");
track.style.cssText = "flex:1;height:8px;background:#e0e0e0;border-radius:4px;overflow:hidden";
// Create progress fill
this._bar = document.createElement("div");
this._bar.style.cssText = "height:100%;border-radius:4px;transition:width 0.3s";
// Create label
this._label = document.createElement("span");
this._label.style.cssText = "min-width:36px;font-size:12px;font-weight:600";
track.appendChild(this._bar);
wrapper.appendChild(track);
wrapper.appendChild(this._label);
this._container.appendChild(wrapper);
this.updateView(context);
}
public updateView(context): void {
const value = context.parameters.probability.raw ?? 0;
const clamped = Math.max(0, Math.min(100, value));
this._bar.style.width = `${clamped}%`;
this._label.textContent = `${clamped}%`;
// Colour coding: green > 70%, amber > 40%, red <= 40%
this._bar.style.backgroundColor =
clamped > 70 ? "#107C10" :
clamped > 40 ? "#FFB900" : "#C50F1F";
}
public getOutputs(): IOutputs { return {}; }
public destroy(): void { this._container.innerHTML = ""; }
}
Scenario: Implement a Web API call to create a Case linked to an Account from an external application.
// External app creating a Dataverse Case via Web API
async function createCase(accessToken, accountId, caseData) {
const orgUrl = "https://contoso.crm.dynamics.com";
const response = await fetch(
`${orgUrl}/api/data/v9.2/incidents`,
{
method: "POST",
headers: {
"Authorization": `Bearer ${accessToken}`,
"Content-Type": "application/json",
"OData-MaxVersion": "4.0",
"OData-Version": "4.0",
"Prefer": "return=representation" // Return created record
},
body: JSON.stringify({
"title": caseData.title,
"description": caseData.description,
"prioritycode": caseData.priority, // 1=High, 2=Normal, 3=Low
"casetypecode": 1, // Question
// Link to Account:
"customerid_account@odata.bind":
`/accounts(${accountId})`,
// Optionally link to Contact:
"primarycontactid@odata.bind":
`/contacts(${caseData.contactId})`
})
}
);
if (!response.ok) {
const error = await response.json();
throw new Error(
`Failed to create case: ${error.error?.message}`);
}
const created = await response.json();
console.log("Created case ID:", created.incidentid);
console.log("Case number:", created.ticketnumber);
return created;
}
Scenario: How do you implement cross-table validation that cannot be done with Business Rules?
Requirement: When closing an Opportunity as Won, validate that a signed Contract exists linked to the opportunity.
Approach: Pre-Operation plugin on Opportunity Update (filtering on statecode)
// Plugin registered on: Update, opportunity, Pre-Operation
// Filtering attributes: statecode
public class OpportunityWinValidation : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
var factory = (IOrganizationServiceFactory)
serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var target = (Entity)context.InputParameters["Target"];
// Only fire when statecode changes to 1 (Won)
if (!target.Contains("statecode")) return;
var newState = target.GetAttributeValue<OptionSetValue>("statecode");
if (newState?.Value != 1) return; // 1 = Won
var service = factory.CreateOrganizationService(context.UserId);
// Check for signed contract linked to this opportunity
var query = new QueryExpression("contoso_contract")
{
ColumnSet = new ColumnSet("contoso_contractid"),
TopCount = 1
};
query.Criteria.AddCondition("contoso_opportunityid",
ConditionOperator.Equal, context.PrimaryEntityId);
query.Criteria.AddCondition("contoso_status",
ConditionOperator.Equal, 2); // 2 = Signed
var contracts = service.RetrieveMultiple(query);
if (contracts.Entities.Count == 0)
{
throw new InvalidPluginExecutionException(
"Cannot mark opportunity as Won: no signed contract found. " +
"Please attach a signed contract before closing.");
}
}
}
8. Cheat Sheet — Quick Reference
Plugin Stage Summary
Stage 10 (Pre-Validation):
→ Outside transaction
→ Before input validation
→ Use: permission checks, external validation
→ NOT rolled back on failure
Stage 20 (Pre-Operation):
→ Inside transaction
→ After validation, BEFORE database write
→ Can modify Target (set defaults, enrich data)
→ Rolled back on failure
→ Use: default values, data enrichment, business validation
Main Operation:
→ Actual database write
Stage 40 (Post-Operation Sync):
→ Inside transaction
→ AFTER database write
→ Target.Id available (new record GUID)
→ Rolled back on failure
→ Use: create related records, update related data
Stage 40 (Post-Operation Async):
→ Outside transaction
→ User interaction not blocked
→ NOT rolled back — fire and forget
→ Use: notifications, background processing, non-critical updates
PCF Lifecycle Summary
init(): called once on load — set up DOM, get initial value
updateView(): called when bound column changes externally or form refreshes
getOutputs(): called after notifyOutputChanged() — return new values
destroy(): called on removal — clean up listeners and libraries
Key API:
context.parameters.{name}.raw → get current value
context.parameters.{name}.formatted → get formatted display value
this._notifyOutputChanged() → signal value changed
context.webAPI.createRecord(table, data) → create record
context.webAPI.retrieveRecord(table, id, query) → retrieve record
context.webAPI.retrieveMultipleRecords(table, query) → list records
context.navigation.openForm({entityName, entityId}) → open record
Web API Quick Reference
Base URL: https://{org}.crm.dynamics.com/api/data/v9.2/
CRUD:
POST /{tablePluralName} → Create
GET /{tablePluralName}(guid)?$select=... → Retrieve
PATCH /{tablePluralName}(guid) → Update
DELETE /{tablePluralName}(guid) → Delete
OData query options:
$select → columns to return
$filter → filter conditions
$orderby → sort order
$top → limit count
$skip → offset (pagination)
$expand → include related entity
$count=true → include total count
Lookup binding in POST/PATCH:
"parentcustomerid@odata.bind": "/accounts(guid)"
Lookup filter in GET:
$filter=_parentcustomerid_value eq {guid}
$filter=parentcustomerid/accountid eq {guid}
Change tracking (delta sync):
Prefer: odata.track-changes header on initial request
Returns OData-DeltaLink → use for incremental sync
Batch:
POST /$batch with multipart/mixed content type
Up to 1,000 operations per batch
Business Rule vs Plugin Decision
Use Business Rule when:
→ Simple show/hide or enable/disable on a form
→ Basic field validation with fixed message
→ Setting default values on new records
→ Non-developer makers need to maintain the logic
→ Client-side only behaviour acceptable
Use Plugin when:
→ Logic requires querying other tables
→ Cross-record validation (e.g., check related records exist)
→ Need to create/update/delete other records
→ External service call needed
→ Complex conditional logic beyond Business Rule capability
→ Must fire on API operations (not just form save)
→ Performance: reusable across all operations
Use Power Automate when:
→ Async background processing (no user wait)
→ Multi-system integration (non-Dataverse services)
→ Long-running processes
→ Notifications (email, Teams)
→ Scheduled processing
→ Non-developer maintainability required
Top 10 Tips
-
Know the event pipeline stages — Pre-Validation (outside transaction), Pre-Operation (inside, before write), Post-Operation Sync (inside, after write), Post-Operation Async (outside). The most tested plugin concept in every .
-
Filtering attributes on Update plugins — always register Update plugins with specific filtering attributes. Without them, the plugin fires on every field update — massive performance impact on busy environments.
-
InvalidPluginExecutionException for user-facing errors — throwing this shows a friendly error in the UI. Throwing any other exception shows an ugly system error. Know this difference for any UX-related plugin question.
-
PCF getOutputs + notifyOutputChanged are paired — when your control's value changes, call notifyOutputChanged() to signal Dataverse. Dataverse then calls getOutputs() to retrieve the new value. Never set the value directly without this flow.
-
Web API OData-bind for lookups — "parentcustomerid@odata.bind": "/accounts(guid)" is the correct syntax for setting lookup values in POST/PATCH. Knowing this notation separates developers who have actually used the Web API.
-
Pre-Operation to set defaults, Post-Operation to create related records — set defaults in Pre-Op (Target can be modified before write). Create related records in Post-Op (the new record ID is available in Target.Id).
-
Plugin depth tracking prevents infinite loops — when Plugin A creates a record that triggers Plugin B which modifies the original record triggering Plugin A again. Check context.Depth > 1 and return early.
-
Managed solutions for all non-dev environments — unmanaged solutions in production are a governance disaster (cannot track changes, cannot cleanly uninstall). Always import managed solutions to Test/UAT/Prod.
-
Environment variables for cross-environment config — never hardcode URLs, API keys, or environment-specific values in plugins or solutions. Use Dataverse environment variables and read them at runtime.
-
Virtual tables for zero-copy external data — surface SAP, SQL, or REST API data as Dataverse tables without replication. The data provider plugin intercepts Retrieve/RetrieveMultiple calls and queries the external system. Know this pattern for any enterprise integration architecture discussion.
