Event Grid with Dataverse

Azure Event Grid is Microsoft's pub/sub eventing service for cloud-scale fan-out. Where Service Bus is durable queueing for transactional messaging, Event Grid is lightweight, high-throughput, multi-subscriber event distribution. Dataverse supports publishing change events to Event Grid, giving access to a fundamentally different integration pattern than the older Service Bus path.

The model. Each Dataverse change event is published to an Event Grid topic as a structured event message. Multiple subscribers can independently subscribe to the topic with their own filters. Each subscriber receives the events it filtered for, processed independently of all other subscribers. If a subscriber is down, the others are unaffected; if a subscriber is fast, the others don't slow it.

Event schema. Dataverse-emitted events follow the CloudEvents v1.0 schema with a Dataverse-specific data payload:

{
  "id": "GUID",
  "source": "dataverse-environment-url",
  "type": "Microsoft.Dataverse.RecordCreated",
  "time": "ISO timestamp",
  "data": {
    "entity": "account",
    "recordId": "GUID",
    "userId": "GUID",
    "changes": { ... }
  }
}

The event metadata is intentionally lightweight — most subscribers fetch the actual record from Dataverse on receipt rather than relying on the event payload alone.

Subscribers. Event Grid supports many subscriber types out of the box:

• Azure Functions — most common. Trigger on event, process, ack.
• Logic Apps — event triggers a Logic App workflow.
• Webhook — HTTP endpoint that receives the event POST.
• Service Bus queue or topic — chain Event Grid to durable queueing for resilient processing.
• Event Hubs — high-throughput streaming.
• Storage queues — for simple low-cost queueing.
• Hybrid Connections — on-premise endpoints.

Filtering. Subscribers can filter events on type, entity name, or attribute values. So one subscriber processes only Account changes; another processes only changes where Status = "Active". Reduces the work each subscriber needs to do.

Reliability. Event Grid retries failed deliveries with exponential backoff for up to 24 hours by default (configurable). After exhausting retries, events can be sent to a dead-letter storage account for inspection. But Event Grid is not durable to the same level as Service Bus — multi-day outages of a subscriber are not the right use case.

Throughput. Event Grid scales to millions of events per second. Suitable for very high-volume Dataverse change streams where Service Bus would be over-provisioned or under-performant.

Pricing. Pay-per-million-events. Generally cheaper than Service Bus at high volume.

Service Bus vs Event Grid for Dataverse.

• Service Bus: durable, ordered, point-to-point or limited pub/sub, moderate scale. Right for transactional integrations where every message must be processed by exactly one consumer, eventually, even after outages.

• Event Grid: pub/sub at scale, many subscribers, eventual consistency, near-real-time, lightweight. Right for fan-out scenarios where many systems should be notified of changes — analytics, search index updates, cache invalidation, low-volume side processes.

Hybrid pattern. Many architectures use both: Event Grid for fan-out to subscribers that care, with one Event Grid subscriber being a Service Bus queue for the transactional consumer.

Operational reality. Event Grid integrations look elegant on paper but require disciplined subscriber operation — every subscriber must be observable, with dead-letter handling and alerting. Without that discipline, dropped events go unnoticed.

Choosing for Dynamics 365. For most Dataverse integrations, Service Bus is the safer default. Reach for Event Grid when:

• You need many independent subscribers.
• Throughput is high enough that Service Bus economics get unfavourable.
• Subscribers are lightweight processors that don't need durable queueing.