A downstream ERP connector processes Dataverse case updates. Every Sunday the connector is taken offline for several hours of maintenance, and no case update may be lost. The connector team can host a Service Bus listener or a webhook receiver. Which design should the developer recommend?
Select an answer to reveal the explanation.
Short Explanation
A queue is a mailbox that holds your letters while you're on vacation. When the connector comes back, everything's waiting. Webhook retries are a courier who eventually gives up, and making users re-save is just moving the outage onto them.
Full Explanation
A queue contract does not need an active listener. Dataverse posts each case update to the Service Bus queue, and the messages stay there, within the queue's message availability settings, until the connector comes back and reads them, so a planned outage of several hours causes delay but no loss. A webhook depends on the receiver being reachable; asynchronous system jobs retry at growing intervals, but the job is eventually stopped and marked failed, and relying on that window for a multi-hour weekly outage is not a design that guarantees delivery. A synchronous webhook would roll back every case save during maintenance, pushing the outage onto users and still losing updates whenever someone does not retry. A cloud flow per update has its own retry policy; when the connector is down the run eventually fails, and a failure email asks a person to recover data by hand. Exam caveat: set the queue's message time-to-live longer than the longest planned outage, and use a topic instead if more than one system needs each update. Operational check: stop the listener in a test environment, update several cases, confirm the queue's active message count grows, then restart the listener and confirm the count drains.