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.