9.3 Event Grid: Custom Events & Filters

Event-Driven AI with Azure Event Grid

Azure Event Grid delivers events from publishers to subscribers using a push model. Unlike a queue that workers poll, Event Grid invokes your endpoint (Azure Function, webhook, Logic App, Service Bus, Event Hubs, and more) when something happens. That makes it ideal for wiring AI platforms together: blob created → start ingestion; model deployment succeeded → refresh configuration; human review approved → resume generation.

The AI-200 skill calls out filters, custom events, and retries. This section focuses on custom events and filters; the next section covers retries and end-to-end workflows.

System Topics vs Custom Topics

Custom topics are first-class on the exam. You create a topic, obtain an endpoint and access keys (or use Microsoft Entra ID auth), and publish JSON events from your AI orchestration code. Subscribers never poll your database for status changes—they react to events.

Event Schemas: Event Grid Schema and CloudEvents

Event Grid accepts events in the Event Grid schema or CloudEvents (JSON) schema. CloudEvents is a CNCF standard widely used for interoperable event-driven systems and is the schema you should prefer for new AI solutions that may span tools and clouds.

A CloudEvents-style payload for an AI job might look like:

{
  "specversion": "1.0",
  "type": "com.openexamprep.ai.document.embedded",
  "source": "/pipelines/embedding",
  "id": "evt-3c91",
  "time": "2026-07-19T18:04:00Z",
  "subject": "documents/tenant-42/doc-7841",
  "dataschema": "https://example.com/schemas/document-embedded.json",
  "data": {
    "documentId": "doc-7841",
    "indexName": "kb-prod",
    "chunkCount": 128,
    "model": "text-embedding-3-large"
  }
}

Key fields subscribers and filters rely on:

• type / eventType — what happened.
• source — which system produced it.
• subject — path-like identifier of the affected entity (excellent for prefix filters).
• id — unique event id for deduplication at the edge.
• data — business payload (keep it small; link to blobs for large artifacts).

When publishing arrays, Event Grid accepts batches of events to a custom topic endpoint—useful when a batch embedding job completes many documents.

Event Subscriptions and Delivery Destinations

An event subscription attaches to a topic and defines:

1. Which events to receive (filters).
2. The destination (handler).
3. Retry and dead-letter settings (next section).

Common destinations in AI architectures:

• Azure Functions (Event Grid trigger) — run lightweight glue: enqueue Service Bus work, update Cosmos DB status, call a Logic App.
• Webhooks — notify an external SaaS or custom API.
• Service Bus queue/topic — bridge from reactive events into durable competing consumers for heavy AI compute.
• Event Hubs — stream events into analytics.

A frequent pattern: Storage BlobCreated (system topic) → Function validates MIME type → sends Service Bus message for OCR → on completion publishes custom Document.Embedded → multiple subscriptions update search and notify UI.

Filters: Deliver Only What Subscribers Need

Without filters, every subscriber receives every event on the topic—wasteful and risky. Event Grid filtering includes:

1. Event type filters — subscribe only to Microsoft.Storage.BlobCreated or your custom com.contoso.ai.job.failed.

2. Subject filters — subject begins with /documents/tenant-42/ and optional ends with .pdf so a tenant-specific pipeline ignores others.

3. Advanced filters — operators on event fields, including data payload keys:

• StringContains, StringBeginsWith, StringEndsWith, StringIn
• NumberGreaterThan, NumberInRange, etc.
• BoolEquals
• IsNull / IsNotNull

Example advanced filter ideas for AI:

• data.chunkCount NumberGreaterThan 0 — skip empty documents.
• data.model StringIn [gpt-4o-mini, gpt-4o] — route only certain model events to cost-control handlers.
• data.safetySeverity StringIn [high, critical] — compliance Function only.

You can combine multiple advanced filters with AND semantics (all must match). Plan subjects and data properties up front so filters stay simple and indexed-friendly.

Custom Events from AI Application Code

Publishing custom events is typically:

1. Construct CloudEvents (or Event Grid schema) objects after a domain state change.
2. POST to the custom topic endpoint with the topic key or token.
3. Rely on Event Grid to authenticate delivery to subscribers (validation handshake for webhooks).

Webhook endpoint validation: Event Grid sends a subscription validation event; your endpoint must echo the validation code. Functions with Event Grid triggers handle this automatically—raw webhooks must implement it or the subscription never activates.

Event Grid vs Service Bus (Decide Deliberately)

• Choose Event Grid when many independent handlers should react to a fact (BlobCreated, EvaluationFinished) with filters and push delivery.
• Choose Service Bus when you need long-running competing consumers, sessions, transactions, or explicit command queues.
• Choose both when Event Grid reacts instantly and then enqueues durable work onto Service Bus for the heavy AI lifting.

Exam Watch-Outs

• Custom topics = your app publishes AI domain events.
• CloudEvents fields (type, subject, data) are what filters and subscribers key off.
• Advanced filters inspect event properties/data—know operators exist beyond simple subject prefix.
• Event Grid pushes; it is not a durable work queue replacement for multi-minute GPU jobs by itself—bridge to Service Bus/Functions with async patterns when work is heavy.