When a new support case is created, a message must be posted to a Teams channel and a ticket must be opened in an external service desk through its REST API. The user's save must not wait for either call, and citizen developers on the support team must be able to maintain the logic. Which approach fits best?
Select an answer to reveal the explanation.
Short Explanation
Think of it like dropping a letter in the outbox: you don't stand there until it's delivered. An automated cloud flow picks the work up after the save, and your support team can open it and change it without a developer. The trap is the synchronous plug-in, which makes every user wait on two outside services.
Full Explanation
Follow-up work that does not need to be part of the transaction, and that the business wants to own, fits an automated cloud flow. The Dataverse trigger for an added row fires after the case is committed, so the user's save completes immediately, and the flow then posts with the Teams connector and calls the service desk through a custom connector that holds the authentication once for the whole team. Run history, retries and connection management come with the platform, and makers can maintain the flow inside a solution. A synchronous PostOperation plug-in runs inside the save, so external latency or a failure in either service slows or breaks case creation, and the logic sits in compiled code the support team cannot maintain. An OnSave script runs only for cases created on a form, misses cases from email, the Web API or imports, and exposes credentials to the browser. Business rules can set values and show messages; they cannot call external services or post messages. Exam caveat: if the external call had to succeed for the case to be valid, a synchronous design would be justified; here the stem rules that out. Operational check: create a case through the Web API and confirm the save returns at once and the flow's run history shows both actions.