[object Object]

When Dataverse needs to tell another system that something happened, you have three native options. They look similar in the Plugin Registration Tool. They behave very differently in production.

Webhooks: synchronous-ish, simple, fragile

Webhooks send an HTTP POST to a URL when a Dataverse event fires. Synchronous webhooks block the calling transaction until the endpoint responds (max 60 seconds). Async webhooks queue.

Pros: dead simple. Any HTTP endpoint works.

Cons: no retry on transient failure (sync), limited retry (async). If the endpoint is down for an hour, you lose events.

Use for: low-volume notifications to internal services with high availability and idempotent receivers.

Azure Service Bus: durable, ordered, harder

Service Bus integration uses queues or topics. Dataverse posts a message; the consumer reads on its own schedule. Messages persist; failures retry; ordering is preserved per session.

Pros: durable, retry-built-in, decouples consumer downtime from Dataverse.

Cons: requires an Azure Service Bus namespace, SAS or managed identity setup, consumer code, and dead-letter queue handling.

Use for: high-volume integration where loss is unacceptable and the consumer is a separate service team.

Event Grid: cloud-native, fan-out, scalable

Event Grid receives Dataverse events and fans out to any number of subscribers (Azure Functions, Logic Apps, third-party webhooks). Subscribers can filter by event type and by record attributes.

Pros: pub-sub model, multiple subscribers per event, built-in retry, native Azure observability.

Cons: requires an Event Grid topic, subscription management, and learning the Cloud Events schema.

Use for: events that need to reach many systems, or where future systems will need to subscribe without changing the producer.

Configuration in Plugin Registration Tool

Plugin Registration Tool -> Register New Service Endpoint
-> Type: Webhook | Service Bus Queue | Service Bus Topic | Event Grid Topic
-> Authentication: Anonymous, HTTP Header, Query String, OAuth, Managed Identity
-> Add Step (just like a plugin) tied to message + table + filter

The synchronous warning

Synchronous webhooks block the user-facing transaction. If your webhook endpoint takes 800ms, every Update on that table is now 800ms slower from the user’s perspective. Default to async. Use sync only when the consumer must influence the transaction outcome.

Authentication patterns

  • Anonymous: do not use in production.
  • HTTP header (API key): acceptable for service-to-service over HTTPS.
  • OAuth bearer: best for endpoints behind Microsoft Entra.
  • Managed identity: for Service Bus and Event Grid, the cleanest pattern; Dataverse acquires a token from the Power Platform managed identity.

Idempotency on the consumer side

Dataverse will retry on failure. The consumer must handle duplicate events. Use the Dataverse correlation ID as the dedupe key. Store consumed IDs for at least 24 hours.

Observability

Service endpoint failures appear in System Jobs with failureCount. Build a Power Automate flow that polls failure count daily and alerts. Without this, your integration silently degrades.

What to do this week

List your service endpoints. For each, document: endpoint type, authentication, retry policy, consumer team, dead-letter strategy. Endpoints without a named consumer team owner are ticking bombs.

[object Object]
Share