A step that posts account updates to an Azure Service Bus endpoint is registered as synchronous. During a Service Bus outage, users saving accounts receive an error and their changes are lost. The business says saves must succeed even when Azure is unavailable, and a short delay in delivery is acceptable. What should the developer change?
Select an answer to reveal the explanation.
Short Explanation
A synchronous post is like refusing to close the shop door until the courier confirms delivery; if the courier's late, nobody gets out. Make it asynchronous and your users' saves complete while a system job keeps retrying delivery. Moving stages doesn't help, since a failure there still cancels the save.
Full Explanation
A synchronous registration runs the post as part of the operation, so a failure to reach the endpoint is returned to the caller and the operation is rolled back. Re-registering the step as asynchronous lets the save commit immediately; the asynchronous service then performs the post as a system job and, for an external Service Bus or network error, retries on an increasing interval while the job waits. Microsoft recommends asynchronous registration for Azure posting for this reason. Moving the step to PreValidation runs it before the main transaction, but an exception raised there still cancels the operation, so users would still lose their saves. A form script affects only the model-driven app; saves from APIs, imports and flows would still fail, and repeated retries do not fix an outage. The queue's message lock duration governs how long a receiver holds a message it is processing; it does not make Dataverse wait for an unavailable namespace. Exam caveat: choose synchronous posting only when the business truly requires the operation to fail if delivery fails. Operational check: block the endpoint in a test environment, save an account, confirm the save succeeds, and watch the related system job retry and then complete once the endpoint is restored.