Approvals as cards – agents in Microsoft 365 (W7, lesson 5)

What you learn in this lesson

send an approval as an Adaptive Card and receive the click in the agent with an action of type Action.Execute

explain why the card carries only an identifier and why the code decides from the sign-in who may confirm

handle double clicks, parallel clicks and old cards so that exactly one decision counts

test card building and click handling without Teams and without the Agents SDK

say what about a card is not verified and stays open

In T7.3 "Human in the loop: approvals", the agent stops before sending and asks. There, a web page answered. Here, Teams answers: The question appears as a card in the chat, with two buttons. A card is convenient and precisely for that reason dangerous: Anyone who sees it can click, and a click arrives as data that someone may have tampered with. This lesson shows how the Kladde builds the card and handles the click without the card deciding anything. Prerequisites are T7.3 and lesson W7.2.2 "Sign-in and rights: who is asking?" (that is where IUserContext is).

State of the checks

Nothing ran against Teams, an Azure Bot or a tenant. Built and tested (test project outside the repository, .NET 10, xunit and Shouldly, 11 tests for card and click, green together with the 13 from W7.2.2, exit code 0) are ApprovalCardFactory and ApprovalCardHandler with stand-ins for the card store, the approvers and the quotes. Not built is the connection to AgentApplication. The SDK names come from Learn; what is not there is open. With a tenant, only a test tenant runs.

This lesson belongs to course W7

You will see the rest of this lesson and its video once you have bought the course. The goals above show what you learn here.

€79.00

incl. VAT, one-time payment

Access to all of the course's lessons with their exercises, solutions and videos on this site, for 24 months from the purchase. A self-study course: no tutoring, no exams or grading by us, and no certificate.

Withdraw from contract here