Showing posts with label Dynamics CRM. Show all posts
Showing posts with label Dynamics CRM. Show all posts

Saturday, 7 February 2026

Mastering Dynamics CRM Plugin Triggers: Pre-Validation, Pre-Operation, Post-Operation, and Async with Azure-Ready Patterns

Dynamics CRM plugin triggers define when your custom logic runs in the Dataverse pipeline. If you understand how Dynamics CRM plugin triggers behave across Pre-Validation, Pre-Operation, Post-Operation, and Asynchronous execution, you can write reliable, idempotent, and production-ready business logic that scales with Azure.

The Problem

Developers struggle to pick the correct stage and execution mode for Dynamics 365/Dataverse plugins, causing issues like recursion, lost transactions, or performance bottlenecks. You need clear rules, copy-paste-safe examples, and guidance on automation, security, and Azure integration without manual portal steps.

Prerequisites

• .NET 8 SDK installed (for companion services and automation)
• Power Platform Tools (PAC CLI) installed
• Azure CLI (az) installed, logged in with least-privilege account
• Access to a Dataverse environment and solution where you can register plugins
• Basic familiarity with IPlugin, IPluginExecutionContext, and IServiceProvider

The Solution (Step-by-Step)

1) Know the stages and when to use each

• Pre-Validation (Stage 10, synchronous): Validate input early, block bad requests before the main transaction. Good for authorization and schema checks.
• Pre-Operation (Stage 20, synchronous): Mutate Target before it’s saved. Good for defaulting fields, data normalization, or cross-field validation.
• Post-Operation (Stage 40, synchronous): Runs after the record is saved, still in the transaction. Good for operations that must be atomic with the main operation (e.g., child record creation that must roll back with parent).
• Post-Operation (Asynchronous): Offload non-transactional, latency-tolerant work (notifications, integrations). Improves throughput and user experience.

2) Messages and images

• Common messages: Create, Update, Delete, Assign, SetState, Associate/Disassociate, Merge, Retrieve/RetrieveMultiple (use sparingly to avoid performance impact).
• Filtering attributes (Update): Only trigger when specific columns change to reduce overhead.
• Images: Use Pre-Image for old values, Post-Image for new values. Keep images minimal to reduce payload and improve performance.

3) Synchronous Pre-Operation example (mutate data safely)

Target framework note: Dataverse runtime support for .NET versions can vary. The C# syntax below follows modern patterns while remaining compatible with the Dataverse plugin model. Always target the supported framework for your environment at build time.

using System;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Extensions; // For helpful extension methods
using Microsoft.Extensions.DependencyInjection; // For DI patterns inside plugin
using System.Globalization;

// File-scoped namespace for clean organization
namespace Company.Plugins;

// Primary-constructor-like pattern for clarity; the Dataverse runtime will call the parameterless constructor.
public sealed class AccountNormalizeNamePlugin : IPlugin
{
    // Build a tiny DI container once per plugin instance to follow DI principles instead of static helpers.
    private readonly IServiceProvider _rootServices;

    public AccountNormalizeNamePlugin()
    {
        var services = new ServiceCollection();
        services.AddSingleton<INameNormalizer, TitleCaseNameNormalizer>();
        _rootServices = services.BuildServiceProvider();
    }

    public void Execute(IServiceProvider serviceProvider)
    {
        // Standard service access from the pipeline
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        var service = factory.CreateOrganizationService(context.UserId);
        var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

        // Guard: Ensure we only run on Update of account and when 'name' changes
        if (!string.Equals(context.PrimaryEntityName, "account", StringComparison.OrdinalIgnoreCase) ||
            !string.Equals(context.MessageName, "Update", StringComparison.OrdinalIgnoreCase))
        {
            return;
        }

        // Prevent recursion: depth should be 1 for first-level execution
        if (context.Depth > 1) return;

        var target = context.InputParameters.Contains("Target") ? context.InputParameters["Target"] as Entity : null;
        if (target == null) return;

        // Run only when 'name' was provided in this Update
        if (!target.Contains("name")) return;

        // Resolve our normalizer from DI
        var normalizer = _rootServices.GetRequiredService<INameNormalizer>();

        // Normalize 'name' to Title Case
        var originalName = target.GetAttributeValue<string>("name");
        var normalized = normalizer.Normalize(originalName);
        target["name"] = normalized;

        tracing.Trace($"AccountNormalizeNamePlugin: normalized '{originalName}' to '{normalized}'.");
    }
}

// Service abstraction for testability and SRP
public interface INameNormalizer
{
    string Normalize(string? input);
}

public sealed class TitleCaseNameNormalizer : INameNormalizer
{
    public string Normalize(string? input)
    {
        if (string.IsNullOrWhiteSpace(input)) return input ?? string.Empty;
        var textInfo = CultureInfo.InvariantCulture.TextInfo;
        return textInfo.ToTitleCase(input.Trim().ToLowerInvariant());
    }
}

Registration guidelines: Register this on account Update, Stage Pre-Operation (20), Synchronous, with filtering attributes = name. Add a minimal Pre-Image if you need original values.

4) Synchronous Post-Operation example (atomic child creation)

using System;
using Microsoft.Xrm.Sdk;

namespace Company.Plugins;

public sealed class ContactCreateWelcomeTaskPlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        var service = factory.CreateOrganizationService(context.UserId);
        var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

        // Only run on Contact Create, after it is created (Post-Operation)
        if (!string.Equals(context.PrimaryEntityName, "contact", StringComparison.OrdinalIgnoreCase) ||
            !string.Equals(context.MessageName, "Create", StringComparison.OrdinalIgnoreCase))
        {
            return;
        }

        if (context.Depth > 1) return;

        var contactId = context.PrimaryEntityId;
        if (contactId == Guid.Empty) return;

        // Create a follow-up task; if this plugin throws, both contact and task roll back
        var task = new Entity("task");
        task["subject"] = "Welcome new contact";
        task["regardingobjectid"] = new EntityReference("contact", contactId);
        task["prioritycode"] = new OptionSetValue(1); // High
        service.Create(task);

        tracing.Trace("ContactCreateWelcomeTaskPlugin: created welcome task.");
    }
}

5) Asynchronous Post-Operation example (offload integration)

Use Async Post-Operation for non-transactional work such as calling Azure services. Prefer a durable, retry-enabled mechanism (queue, function) over direct HTTP. The plugin should enqueue a message; an Azure Function (managed identity) processes it.

using System;
using Microsoft.Xrm.Sdk;

namespace Company.Plugins;

public sealed class ContactCreatedEnqueueIntegrationPlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        var service = factory.CreateOrganizationService(context.UserId);
        var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

        if (!string.Equals(context.PrimaryEntityName, "contact", StringComparison.OrdinalIgnoreCase) ||
            !string.Equals(context.MessageName, "Create", StringComparison.OrdinalIgnoreCase))
        {
            return;
        }

        // Idempotency key: use the contact id
        var contactId = context.PrimaryEntityId;
        if (contactId == Guid.Empty) return;

        // Example: write an integration record for downstream Azure Function (poll or Dataverse Change Tracking)
        // This avoids secrets and direct outbound calls from the plugin.
        var integrationLog = new Entity("new_integrationmessage"); // Custom table
        integrationLog["new_name"] = $"ContactCreated:{contactId}";
        integrationLog["new_payload"] = contactId.ToString();
        service.Create(integrationLog);

        tracing.Trace("ContactCreatedEnqueueIntegrationPlugin: queued integration message.");
    }
}

6) Automate registration with PAC CLI (no manual portal)

:: Batch/PowerShell snippet to build and register the assembly
:: 1) Build plugin project (target a runtime supported by your environment)
dotnet build .\src\Company.Plugins\Company.Plugins.csproj -c Release

:: 2) Pack into a solution if applicable
pac solution pack --zipFilePath .\dist\CompanySolution.zip --folder .\solution

:: 3) Import or update solution into the environment
pac auth create --url https://<yourorg>.crm.dynamics.com --cloud Public
pac solution import --path .\dist\CompanySolution.zip --activate-plugins true

This keeps registration repeatable in CI/CD without manual steps.

7) Azure companion Minimal API (for outbound webhooks or admin tools)

For external processing, build a Minimal API or Azure Function with managed identity and Azure RBAC. Example Minimal API (.NET 8) that reads from Storage using DefaultAzureCredential.

using Azure;
using Azure.Identity;
using Azure.Storage.Blobs;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Azure;
using Microsoft.Extensions.DependencyInjection;

var builder = WebApplication.CreateBuilder(args);

// Use DefaultAzureCredential to prefer Managed Identity in Azure and dev fallbacks locally
builder.Services.AddAzureClients(az =>
{
    az.UseCredential(new DefaultAzureCredential());
    az.AddBlobServiceClient(new Uri(builder.Configuration["BLOB_ENDPOINT"]!));
});

var app = builder.Build();

// Simple endpoint to fetch a blob; secure this behind Azure AD (AAD) in production
app.MapGet("/files/{name}", async (string name, BlobServiceClient blobs) =>
{
    // Access container 'docs' with RBAC: Storage Blob Data Reader/Contributor on the Managed Identity
    var container = blobs.GetBlobContainerClient("docs");
    var client = container.GetBlobClient(name);

    if (!await container.ExistsAsync()) return Results.NotFound("Container not found.");
    if (!await client.ExistsAsync()) return Results.NotFound("Blob not found.");

    var stream = await client.OpenReadAsync();
    return Results.Stream(stream, "application/octet-stream");
});

await app.RunAsync();

Required Azure RBAC role for the app's managed identity: Storage Blob Data Reader (read-only) or Storage Blob Data Contributor (read-write) on the storage account or specific container scope.

8) IaC with Bicep: storage + managed identity + role assignment

// main.bicep
targetScope = 'resourceGroup'

param location string = resourceGroup().location
param storageName string
param identityName string = 'dv-plugin-mi'

// Storage Account
resource stg 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

// User Assigned Managed Identity
resource uami 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: identityName
  location: location
}

// Blob Data Reader role on storage for the identity
resource role 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(stg.id, uami.id, 'ba92f5b4-2d11-453d-a403-e96b0029c9fe') // Storage Blob Data Reader
  scope: stg
  properties: {
    principalId: uami.properties.principalId
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'ba92f5b4-2d11-453d-a403-e96b0029c9fe')
    principalType: 'ServicePrincipal'
  }
}

Deploy with: az deployment group create -g <rg> -f main.bicep -p storageName=<name>.

Best Practices & Security

Pick the right trigger

• Pre-Validation: Reject invalid input early (authorization, schema, required business rules).
• Pre-Operation: Mutate data before save, avoid external calls here.
• Post-Operation (sync): Keep logic small and deterministic to minimize transaction time.
• Post-Operation (async): Offload long-running and I/O-heavy work.

Recursion, idempotency, and performance

• Check context.Depth to prevent infinite loops.
• Use idempotency keys (primary entity id) in integration logs.
• Keep images and columns minimal; filter attributes to reduce trigger noise.
• Use AsNoTracking() in external EF Core services when reading data.

Pro-Tip: Use AsNoTracking() in Entity Framework when performing read-only queries to improve performance.

Security and authentication

• Use Azure AD and Managed Identity for external services; never store secrets in plugin code.
• Apply least privilege with Azure RBAC. Examples: Storage Blob Data Reader/Contributor for the app workload identity; Key Vault Secrets User if retrieving secrets via a separate process.
• In Dataverse, ensure the application user has the minimal security roles necessary for the operations (table-level privileges only on the entities it touches).

Automation and IaC

• Use PAC CLI and CI/CD to register and update plugins, avoiding manual portal steps.
• Use Bicep or azd to provision Azure resources, assign RBAC, and configure endpoints.

Error handling and resiliency

• Synchronous plugins should throw InvalidPluginExecutionException only for business errors that must roll back the transaction.
• For external work, prefer async steps that enqueue messages and rely on Azure Functions with retry policies and dead-letter queues (e.g., Azure Storage Queues or Service Bus).
• Trace key events with ITracingService for diagnosability.

Testing strategy

• Abstract logic behind interfaces and inject into the plugin to enable unit testing without Dataverse.
• Use fakes for IOrganizationService and validate behavior under different stages and messages.
• Add integration tests in a sandbox environment using PAC CLI to seed and verify behavior.

References

• Azure RBAC built-in roles: https://learn.microsoft.com/azure/role-based-access-control/built-in-roles
• DefaultAzureCredential: https://learn.microsoft.com/dotnet/api/azure.identity.defaultazurecredential
• Power Platform CLI: https://learn.microsoft.com/power-platform/developer/cli/introduction

Summary

• Choose the correct trigger: Pre-Validation for guards, Pre-Operation for mutation, Post-Operation for atomic side-effects, Async for integrations.
• Enforce security: Managed Identity for auth, Azure RBAC with least privilege, and no secrets in code.
• Automate everything: PAC CLI for plugin registration, Bicep for Azure resources, and add retries and dead-lettering for resilient async flows.

Wednesday, 21 January 2026

Dynamics CRM and Model-Driven Apps in Power Apps: The Complete, No-Fluff Guide

Dynamics CRM and model-driven app in Power Apps are core pieces of Microsoft’s business application stack that help teams design scalable, secure, and data-driven solutions with minimal code. This guide explains what each is, how they connect, when to use them, and how to get started—complete with practical examples.

What is Dynamics CRM (Dynamics 365 Customer Engagement)?

Originally known as Dynamics CRM, Microsoft now delivers these capabilities through Dynamics 365 Customer Engagement (CE) apps like Sales, Customer Service, and Marketing. These apps run on Microsoft Dataverse, offering standardized tables (Accounts, Contacts, Leads, Opportunities, Cases) and robust features like security roles, business process flows, audit history, and integration with Microsoft 365 and Azure.

  • Purpose-built apps: Sales pipeline, service case management, field service, and more.
  • Enterprise-grade platform: Role-based security, activity tracking, SLA management, and analytics.
  • Extensible: Customize with Power Platform (Power Apps, Power Automate, Power BI) and Azure services.

What is a Model-Driven App in Power Apps?

A model-driven app is a Power Apps application generated from your data model in Dataverse. Instead of pixel-perfect canvas design, you define tables, columns, relationships, forms, views, charts, dashboards, and the app renders responsive UI automatically across devices.

  • Metadata-driven: Configure data structure and business rules; the UI follows.
  • Built-in UX patterns: Grids, forms, advanced filtering, and command bar actions.
  • Process automation: Business rules, business process flows (BPFs), and Power Automate flows.

How Dynamics CRM and Model-Driven Apps Work Together

Dynamics 365 CE apps are essentially first-party model-driven apps built on Dataverse with Microsoft’s prebuilt tables and logic. You can extend these apps or create your own model-driven apps alongside them to address specialized processes—reusing the same security, data, and automation framework.

  • Shared data: Use Accounts, Contacts, and custom tables in both Dynamics 365 and your model-driven apps.
  • Unified security: Apply the same roles, field security, and auditing across apps.
  • Coexistence: Extend Sales or Customer Service with custom model-driven apps for unique teams or regions.

Model-Driven Apps vs. Canvas Apps

  • Model-driven apps: Best for data-intensive processes, standardized UIs, enterprise security, and rapid configuration.
  • Canvas apps: Best for tailored, pixel-perfect experiences, task apps, and multi-connector mashups.
  • Hybrid approach: Use model-driven for core records and processes; embed canvas components for specialized screens.

When to Use Model-Driven Apps

  • Complex data relationships: Many related tables (e.g., Accounts → Opportunities → Quotes).
  • Strict governance: Need audit trails, role-based access, field-level security, and compliance.
  • Process-centric work: Guided stages with approvals and SLAs using business process flows.
  • Fast time-to-value: Configure metadata, not custom code, to deliver quickly.

Step-by-Step: Build a Model-Driven App

  • 1. Plan your data model: Identify tables (e.g., Deals, Accounts), columns (e.g., Deal Value), and relationships.
  • 2. Create tables in Dataverse: Add columns, set data types, define relationships and choice fields.
  • 3. Design forms and views: Build main forms, quick create forms, and list views with relevant columns and filters.
  • 4. Add business rules and BPFs: Enforce field logic and create stage-based process guidance (Qualify → Propose → Close).
  • 5. Add charts and dashboards: Visualize KPIs like open deals, case backlogs, or SLA breaches.
  • 6. Secure the app: Configure security roles, field security profiles, and sharing as needed.
  • 7. Build the app shell: In Power Apps, create a model-driven app, add navigation areas, tables, views, and dashboards.
  • 8. Automate: Use Power Automate for notifications, approvals, and integrations (e.g., Teams, Outlook, SharePoint).
  • 9. Test and publish: Validate role-based experiences, performance, and data quality rules before rollout.

Real-World Examples

Sales Pipeline Management

Create tables for Leads, Opportunities, Products, and Quotes. Use a BPF to guide reps from Qualify to Close, automate quote approval with Power Automate, and surface a dashboard showing pipeline by stage and forecast category.

Customer Service Case Management

Use Cases, Queues, and SLAs. Route incoming cases based on topic and priority, track response times, and surface knowledge articles. Enable agents to update records via a streamlined model-driven interface.

Partner Onboarding Portal (with Power Pages)

Maintain Accounts and Partner Profiles in Dataverse. Expose selected data externally through Power Pages, while internal teams manage approvals and reviews in a model-driven app.

Key Benefits

  • Consistency: Standardized UI and validated data entry across teams.
  • Compliance-ready: Audit logs, security roles, and field-level security.
  • Scalable: Handles complex schemas and large user bases.
  • Low-code agility: Configure quickly, extend with pro-code when needed.

Best Practices and Governance

  • Solution-first development: Use managed/unmanaged solutions, publisher prefixes, and ALM pipelines.
  • Naming and schema discipline: Use consistent table/column naming and choice values.
  • Security by design: Define least-privilege roles early; avoid broad org-level permissions.
  • Data quality: Use required fields, duplicate detection, and business rules to enforce standards.
  • Performance: Optimize views, indexes, and avoid overly complex client scripts.
  • Documentation: Capture data model diagrams, process maps, and support playbooks.

FAQ

Is Dynamics CRM the same as Dynamics 365?

The term “Dynamics CRM” refers to the legacy branding. Today, capabilities are delivered through Dynamics 365 Customer Engagement apps (e.g., Sales, Customer Service) running on Dataverse.

Do I need Dynamics 365 to build a model-driven app?

No. You can build standalone model-driven apps on Dataverse. However, many organizations combine them with Dynamics 365 for richer, out-of-the-box capabilities.

Can I integrate with Outlook, Teams, or SharePoint?

Yes. Model-driven apps integrate with Microsoft 365, enabling email tracking, file storage, collaboration, and notifications.