9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool

Dataverse doesn't just react to changes internally through plug-ins — it can actively push notifications about those changes out to external Azure services and HTTP endpoints so that other systems learn about a create, update, or delete almost as soon as it happens. This publish-side integration pattern is registered through a Service Endpoint and triggered through the IServiceEndpointNotificationService interface, and it's the mechanism PL-400 candidates are expected to know for getting Dataverse event data out to the rest of an organization's Azure estate.

The Service Endpoint Record

A Service Endpoint is a Dataverse record (the ServiceEndpoint table) that stores the connection information for an external destination — an Azure Service Bus queue or topic, an Azure Event Hub, or a webhook URL. You create it using the Plug-in Registration Tool (PRT), supplying the namespace, authentication values, and contract type for the destination. Once a service endpoint exists, you register a step in the event execution pipeline (the same message/table/stage combination you'd use for any plug-in step) that identifies which Dataverse events should be sent to it.

There are two distinct ways to make that step actually fire a notification:

Option 1: Direct Step Registration (No Custom Code)

Dataverse ships an out-of-box (OOB) Azure-aware plug-in. You register a step for this OOB plug-in against your service endpoint in PRT, specifying the message and table combination that should trigger it. When that combination occurs, the OOB plug-in runs automatically and calls IServiceEndpointNotificationService on your behalf to post the current data context to the destination — no assembly to write or deploy. This is the fastest path when you simply want "every create on this table goes to this queue" with no filtering or transformation logic.

Option 2: A Custom Azure-Aware Plug-in

When you need to decide whether to publish, reshape the payload, or combine the notification with other business logic, you write your own plug-in and call the service explicitly:

IServiceEndpointNotificationService notificationService =
    (IServiceEndpointNotificationService)serviceProvider.GetService(
        typeof(IServiceEndpointNotificationService));

string response = notificationService.Execute(
    new EntityReference("serviceendpoint", serviceEndpointId),
    context);

Execute takes an EntityReference to the registered ServiceEndpoint record and a RemoteExecutionContext (the same execution context available inside any plug-in, cast to its remote form), and posts it to the endpoint. For a two-way contract, the destination can return a string value back into response, letting a listener application talk back to the transaction that triggered the notification. This is the pattern for conditional publishing — for example, only notifying an order-fulfillment system when an order's status changes to "Ready to Ship," rather than on every field update.

Execution Mode Matters

Whichever option you choose, the step that triggers the notification should almost always be registered to run asynchronously. Asynchronous registration hands the post off to a system job managed by the asynchronous service, so the user's save operation isn't held up waiting on network round-trips to Azure. You can review the status of each notification attempt in System Jobs, and Dataverse retries a failed post in an exponentially increasing backoff pattern before marking the job Failed.

Payload Size Limits

The data context posted to the endpoint carries the entity attributes, input parameters, and any pre/post images attached to the step. If the total payload exceeds 192 KB, Dataverse strips the ParentContext, InputParameters, PreEntityImages, and PostEntityImages properties before sending, and flags the message with a MessageMaxSizeExceeded property so the listener knows data was truncated. If the payload is still over 192 KB after that trimming, the post fails outright. This is a practical reason to keep registered images narrow (specific attributes only, not the full entity) on any step that feeds a service endpoint.

Comparing the Two Publishing Approaches

Both approaches ultimately rely on the same underlying mechanism — the service endpoint notification service posting a RemoteExecutionContext to whatever destination the ServiceEndpoint record describes. Understanding that shared foundation is what lets you reason correctly about the next section's destination choices: webhook, Service Bus queue, Service Bus topic, or Event Hub.