An integration team wants every update to an account row published to an existing Azure Service Bus queue. They will use the Plug-in Registration Tool and do not want to write or deploy any plug-in code. Which sequence accomplishes this?
Select an answer to reveal the explanation.
Short Explanation
It's two moves: tell Dataverse where the mailbox is, then tell it which events to drop in. Register the service endpoint, then hang a step off it. You don't need an assembly, because the built-in Azure-aware plug-in does the posting for you.
Full Explanation
With the Plug-in Registration Tool, a team first registers a new service endpoint, typically by pasting the Service Bus shared access signature connection string so the tool fills in the namespace, path and contract, and chooses the message format. It then registers a step on that service endpoint, selecting the Update message and the account table, usually in asynchronous mode. The out-of-box Azure-aware plug-in posts the execution context through the service endpoint notification service, so no custom assembly is required. Registering an assembly with a posting plug-in is the custom-code route the team wants to avoid, and steps are not associated with queues in that way. A webhook endpoint posts an HTTP request with the execution context to a web receiver; pointing it at a queue URL does not create Service Bus messages with the right authentication and contract. A step's configuration fields pass strings to a plug-in; they are not where a service endpoint is defined, and a step cannot exist before the endpoint it belongs to. Exam caveat: the same pattern applies to topics and Event Hubs; only the contract and connection details change. Operational check: update a test account and confirm a message appears in the queue and the related system job shows success.