AB-400: Publishing Dataverse Events to External Services

Introduction

Choose a Dataverse event delivery path from the consumer's operating contract: use a webhook for an HTTP receiver that can absorb the expected traffic, Azure Service Bus when queued work or independent subscriptions are needed, and Azure Event Hubs when the destination is an event-stream processing system. Then register the destination separately from the event condition. A Plug-in Registration Tool step provides declarative publication; a custom plug-in can call IServiceEndpointNotificationService when publication needs an explicit code decision. Neither choice removes the need to handle repeated delivery and downstream failure.

Publishing Dataverse events to external services requires agreement on what acceptance means. Prefer asynchronous PostOperation delivery for work that follows a committed change. Define which context fields the consumer requires, how it authenticates the sender, and how it records completion before enabling the step. A completed Dataverse publication job and a completed external business action are different observations; the receiver must make that difference visible.

This guide uses an illustrative facilities integration in which a saved service-request update refreshes an external dispatch projection. The procedure and expected observations below are design guidance, not results from an executed tenant. It covers transport and consumer contracts; defining a named business event and implementing a full data synchronization algorithm are separate tasks.

Architecture Overview: Choose the Delivery Contract

Microsoft's webhook guidance distinguishes direct HTTP delivery from Service Bus queuing. Webhooks can use synchronous or asynchronous steps; the documented Service Bus integration uses asynchronous steps. The following decision framework adds application-design recommendations to those platform distinctions.

Consumer requirement	Starting choice	Consequence to design and verify
One service already accepts HTTP notifications and can handle expected bursts	Asynchronous webhook	Receiver capacity and durable acceptance become part of the integration; direct HTTP is not a built-in backlog for a prolonged outage.
Workers must catch up after being unavailable	Service Bus queue contract	Provision the broker and consumer independently; choose message lifetime and a recovery process before relying on the backlog.
Several applications need their own delivery path	Service Bus topic contract	Treat each subscription's processing, authorization and failure recovery as a separate consumer responsibility.
Existing analytics or stream processors consume an event stream	Event Hubs contract	Confirm the stream consumer's retention, position tracking and replay design separately; do not reuse a work-queue completion design without review.
A caller must immediately observe receiver availability	Synchronous webhook, only after evaluating coupling	The caller waits for the remote dependency, and an external effect cannot be undone by rolling back the Dataverse transaction.

The Azure integration documentation also describes relay-oriented contracts. A one-way relay needs an active listener, unlike a persistent queue. Two-way and REST contracts support response-oriented interactions. They are not substitutes for a queued worker simply because all are represented by a service endpoint. Identify the selected endpoint contract explicitly in the design record.

For the dispatch projection, a queue is a reasonable starting recommendation: dispatch can briefly stop without making service-request editing depend on its availability. Event Hubs would require a distinct stream-consumer design; it is not automatically preferable because the inputs are called events. A webhook can also work if its receiver durably accepts notifications and capacity tests demonstrate that it handles bursts.

Core Components and Their Contracts

The endpoint and the step answer different questions

A service endpoint describes where and under which transport/security contract Dataverse sends context. A message-processing step describes when publication is eligible: message, primary table, pipeline stage and execution mode. Registering a destination alone does not subscribe it to every row change.

The Plug-in Registration Tool configures these event-framework extensions. For the built-in Azure-aware publication path, register the service endpoint and its event step; a separate custom assembly is unnecessary merely to forward context. A custom Azure-aware plug-in is appropriate when application logic must choose whether to notify a configured endpoint. It obtains IServiceEndpointNotificationService and invokes it with the registered service endpoint reference and current execution context. The notification service uses platform endpoint configuration; it is different from constructing a general HTTP or Azure client inside the plug-in. Webhooks can also be invoked through this service without a separate endpoint step.

Choose one publication owner for each intended notification. Registering an automatic endpoint step and calling that endpoint from another plug-in for the same event can create two publication paths. Consumer deduplication remains necessary, but it should not hide accidental double registration.

RemoteExecutionContext is an operation context

The external payload represents RemoteExecutionContext. It carries operation and environment information alongside parameters and available entity images. It is not a promise that the receiver receives every column or a complete historical record. For an Update, a submitted column can trigger a filtered step even when its value is unchanged. An absent attribute must not be interpreted as an instruction to clear that attribute.

Define an adapter at the consumer boundary. Validate the expected organization, message and primary table, extract the permitted fields, and convert the context into the receiver's own versioned work record. Preserve correlation information for diagnosis, but do not assume a correlation identifier is the unique identity of a business effect. Several extensions or operations may be part of one correlated activity.

Payload completeness must be checked. Microsoft documents different size-handling rules for the two delivery paths: oversized webhook payloads are flagged and can omit context collections; Azure publication can similarly truncate context or fail to send. Treat a size indicator or missing required collection as a contract failure. Keep configured images narrow and avoid silently performing work with incomplete data. Re-querying a row can establish its current state, but cannot reconstruct an earlier snapshot that was never retained.

How Components Work Together: Register a Bounded Publication

Use an isolated Dataverse environment, a dedicated external test destination and synthetic rows. Obtain authorization to register extensions and to configure the Azure resource or HTTP receiver. Confirm resource costs, access permissions and secret-handling arrangements before connecting real data. Do not send a production execution context to a public request-capture site.

For the example, assume a custom contoso_servicerequest table and a contoso_dispatchstatus column already exist. These are illustrative schema names, not built-in components. The consumer refreshes a projection of current dispatch status; the notification does not authorize dispatching a technician or charging a customer.

Define the receiving contract first. Record the permitted environment, Update message, primary table, required row identifier, accepted context format and allowed data fields. Decide that repeated notifications may cause a projection refresh, but may not create an additional real-world action. Define how malformed or incomplete context is quarantined and who can inspect it.
Configure the destination. For the queue option, create the intended Azure Service Bus resource and queue, grant Dataverse the documented send authority, and give the listener only its required receiving authority. Register a service endpoint with the matching queue contract and address, authentication configuration and an explicit supported message format. JSON is useful for a non-.NET consumer; it still requires a parser for Dataverse's serialized context structures. For a webhook alternative, configure an authenticated receiver and register its endpoint and matching header or query-key authentication. Prefer credentials in headers where the hosting arrangement allows it, and redact credentials from all logs.
Associate the event step. In the Plug-in Registration Tool, attach the publication step to the endpoint, select Update and the specific primary table, then choose PostOperation and Asynchronous. Set the filtering attribute to contoso_dispatchstatus; do not add the primary key to that filter. Record the run-as identity and execution order deliberately. Verify the exact message/table combination is supported in the environment.
Configure only required context. If the consumer needs an image supported by the selected registration, choose a documented alias and only required columns. Verify the serialized payload from a synthetic operation rather than assuming the alias or attribute layout. For a current-state projection, the row identifier plus an authorized later read may be sufficient. That read requires its own Dataverse identity and permission design.
Inspect acceptance at every boundary. Save a synthetic update, inspect the asynchronous publication job, then correlate receiver intake and projection-processing records. An accepted broker post proves the publication boundary was crossed. A projection completion record proves a different action. Do not infer the second from the first.

Use the programmatic alternative only when it adds a real condition, such as notifying one approved endpoint after a plug-in determines that the operation is eligible. Register the endpoint first, configure its environment-specific identifier, register the publishing plug-in on the intended event, and call IServiceEndpointNotificationService with that endpoint and context. Review the host step's stage and mode; moving a notification into code does not make remote effects part of an atomic Dataverse transaction. Keep the destination identifier configurable across environments and keep credentials in the supported endpoint security configuration.

This publication procedure deliberately uses a table update. A named business-event definition is handled in AB-400: Custom APIs, Business Events and Plug-in Identity. Pipeline implementation foundations are explained in AB-400: Dataverse Plug-ins and the Event Execution Pipeline.

Design Considerations: Acceptance, Replay and Security

Make acceptance recoverable

For an asynchronous webhook, a useful receiver design authenticates, validates and durably stores work before returning success. A success response sent before durable acceptance can lose work if the process then stops. A failure sent after a durable write can produce another attempt, so the intake write must tolerate repetition. Dataverse evaluates the HTTP status rather than using the response body as an application result.

For the Service Bus path, track broker intake and worker completion separately. Microsoft documents publication retries and system-job errors, but that is not an end-to-end exactly-once promise. A consumer should likewise survive a stop between recording its business result and acknowledging the transport. Acknowledgment and failure-handling details must match the selected consumer library and endpoint contract.

The projection scenario can safely coalesce repeated row notifications and refresh current state, provided concurrent workers cannot overwrite newer projection state with an older read. Define that concurrency rule in the receiver. If the requirement changes to performing an irreversible action for every transition, a row identifier or correlation identifier alone is insufficient: establish a stable, durably retained business-effect identity and an atomic uniqueness decision at the effect boundary before enabling it. A table-update notification is not automatically a uniquely defined business transition.

Preserve a receiving record with the accepted identity, schema version, payload fingerprint, outcome, attempts and diagnostic correlation. For intentional replay, reuse the original identity and record the replay operator/reason. Never assign a new business identity just to bypass a completed record. Retain only the data needed for the agreed recovery period, and restrict access to retained contexts.

Treat transport trust and data authorization separately

For the documented Azure integration, Shared Access Signatures authorize publication and receiving. Separate sending and listening permissions and rotate the configured secrets through a tested change process. A webhook requires validation of its configured authentication credentials over a protected transport. Organization and message headers help route and diagnose a request; they do not replace authenticating its sender.

An external receiver does not inherit Dataverse row or column security enforcement for data it has already received. Minimize outbound context, restrict its storage and logs, and authorize any later Dataverse reads independently. The selected step's execution identity also deserves review; do not solve a failed read by casually elevating the publisher to a broadly privileged identity.

Common Mistakes and Observable Failure Tests

Validate the design with expected observations in a disposable environment. The following are acceptance criteria, not recorded test results.

Deliberate condition	Expected evidence and decision
Update the filtered column, then update only an unrelated column	Intended publication appears for the eligible request; unrelated edits do not generate the configured notification. Submitting the filtered column unchanged is tested separately.
Stop the queue consumer while publishing synthetic updates	Distinguish successful Dataverse posting from unprocessed consumer work; verify configured message lifetime and recovery before approving the outage tolerance.
Reject webhook authentication	No work is accepted, the response indicates failure, and the asynchronous job/receiver logs identify the rejection without exposing secrets.
Crash after durable intake but before processing completes	The original work remains recoverable; restarting must not create an untracked second business effect.
Replay the same accepted notification twice	Intake and effect records show repetition; the projection remains correct and only the intended effect is recorded.
Omit a required image or supply a payload-size indicator	The receiver quarantines or explicitly reconciles the incomplete notification; it does not substitute null values and proceed silently.
Allow a synchronous webhook to act, then cause the Dataverse operation to fail	The design recognizes that an already-sent request cannot be recalled; this is grounds to reconsider synchronous coupling for irreversible work.

For a failed asynchronous publication, inspect the Dataverse System Job first. Then inspect destination authentication and availability, followed by receiver intake and processing state. A completed job with no business completion usually calls for consumer-side investigation, not another Dataverse update. Microsoft documents a webhook timeout and limited retry behavior for certain gateway/service errors; do not treat all HTTP failures as an indefinite platform retry policy. Broker-backed publication has its own asynchronous retry behavior, which likewise does not prove eventual business completion.

After testing, disable the test step before stopping or deleting its destination. Drain or deliberately discard only synthetic pending work, remove test registrations and resources no longer needed, and revoke test credentials. Deleting a queue before disabling its publisher can turn cleanup into a stream of avoidable failures.

Certification Relevance

Within the frozen AB-400 scope verified October 15, 2026 for effectiveness October 16, event publication belongs to Develop integrations. The useful skill is connecting transport choice, endpoint registration and receiver behavior into one defensible contract. This scope statement does not independently confirm live exam availability. AB-400: Synchronizing Dataverse with Change Tracking and Upsert addresses the separate requirement to reconcile dataset state when notifications alone are insufficient.

Conclusion

Choose the transport by outage tolerance, consumer shape and acceptance requirements. Register the destination and event condition explicitly, inspect the actual remote context, and make replay safe at the consumer's business-effect boundary. Approve the integration only when publication failure, accepted-but-unfinished work and completed processing can be distinguished through observable evidence.