An asynchronous step posts account changes to an Azure Service Bus topic. The namespace is unreachable for 20 minutes because of a network problem, and several accounts are updated during that time. What happens to those account events?
Select an answer to reveal the explanation.
Short Explanation
An asynchronous post is like dropping a parcel at a courier who keeps trying the door until someone answers. The account saves already went through, and the system jobs keep knocking. Rollbacks are a synchronous problem, and nothing flips your step's mode for you.
Full Explanation
With asynchronous registration, the account update commits first and the posting runs as a system job of the asynchronous service. When the Service Bus or network is unavailable, the message is not posted and the system job enters a waiting state; the asynchronous service retries in an exponential pattern, frequently at first and then at longer intervals, so a short outage normally ends with the events delivered. If the endpoint stays unavailable long enough, the job is eventually stopped and marked failed, which is why monitoring system jobs matters. Rollback happens only with synchronous registration, where a posting failure is returned to the operation. Asynchronous posting is not fire-and-forget with a single attempt; retry behavior is part of the design. Dataverse never changes a step's execution mode automatically; mode is fixed by the registration. Exam caveat: an internal Dataverse error is not retried in the same way, because retries apply to external Service Bus or network errors. Operational check: filter system jobs for the posting operation, confirm jobs that waited during the outage show completed after it, and investigate any job in a failed status.