Approvals in Microsoft Teams and on mobile: how to design a decision card (Adaptive Cards)

Take a hypothetical distribution company with 90 employees. The warehouse manager receives an email: “Please approve the invoice in the system.” They have to open a laptop, log in, find the document and only then decide. The check itself takes a moment, but the whole operation takes several minutes, so the email waits until the evening.

An approval card in Teams reverses this order. The manager receives a small window in the chat: supplier, amount, order number, whether the invoice matches the order, and “Approve” and “Reject” buttons. They make the decision where they read their messages anyway – including on their phone.

Microsoft builds these windows in the Adaptive Cards format. It is a description of a card with text, a few fields and buttons, which Teams and Outlook display in a conversation or in the body of an email. You do not need to know it to use approvals, but it is worth knowing that the card’s appearance can be tailored to your own documents.

You have two options. The first is ready-made Power Automate approvals: the flow sends a request and the approver responds in Teams or Outlook. They can also use the Power Automate action centre, a page listing the matters awaiting their decision. Microsoft prepares the look of the request itself, and the decision history is saved automatically.

The second option is your own card, sent to a chat with the “Post adaptive card and wait for a response” action. The flow waits until someone clicks a button and only then continues. This gives you complete freedom over the layout, but you have to design the card and record the decision history yourself.

This action has one pitfall. According to Microsoft documentation, it accepts a response from any user who can see the card. If you send it to a team channel, any member of the team can approve the invoice – so send decision cards to a chat with a specific person. You will find a comparison of the two options in the table below.

A good card has three parts. At the top, one sentence saying what it is and who it is from, for example “Invoice: forklift servicing, PLN 12,400 gross”. Below that, the few details needed for the decision, and at the bottom the buttons and a link to the full document.

The most common mistake is putting every field from the system on the card. Thirty fields look thorough, but on a phone they mean scrolling and hunting for the amount. Adopt a simple rule: everything needed for the decision fits on one phone screen without scrolling. In practice, that is usually four to six fields.

There should be no more than three buttons: approve, reject and return with a comment. Show the comment field only after reject or return is selected. You will find a sample set of fields for four typical documents in the table below.

Whether a manager clicks on the train depends first on the notification. A message saying “New message from Workflows” (the name of the Power Automate app in Teams) will be ignored. A message saying “Invoice: forklift servicing, PLN 12,400, decision by Thursday” shows straight away whether the matter is urgent.

The second point is testing on a real phone. Microsoft recommends checking cards on narrow screens, because a layout that looks fine on a computer can get cut off on a phone. According to documentation from August 2026, the Teams mobile app supports cards up to version 1.6 – newer elements may not display correctly.

The third point is Outlook. Ready-made Power Automate approvals work in it straight away. A custom card built for Teams will not carry over automatically, however, because Outlook handles cards under different rules and does not display some of the buttons used in Teams. If some managers work mainly in email, plan two versions or stick with ready-made approvals.

A phone is not suitable for every decision. Write down what may be approved from the card preview and what requires opening the document:

The card is only a window. Who receives it and in what order is set by the flow in Power Automate. Ready-made approvals come in five types, each suited to a different situation – we describe them in the list at the end of this section.

Majority voting, such as the agreement of three out of five board members, is not one of the ready-made types. It can be built by collecting everyone’s responses and counting the votes in the flow. However, that is extra logic to maintain, so first check whether the agreement of the CEO and one board member would be enough.

Whatever the type, every path needs a deadline and a deputy. A single Power Automate flow run lasts no more than 30 days, after which pending approvals expire. A reminder after two days and passing the matter to a deputy after three is a sensible starting point.

With ready-made approvals, Power Automate records who made the decision, when and with what comment. The approver acts under their own work Microsoft 365 account, so there is no doubt about who clicked. With a custom card, you have to design this record yourself, for example as an entry in a SharePoint list.

After the decision, the card should change: instead of buttons, it should show “Approved, Anna Nowak, 14:32”. Teams lets you update a card that has already been sent using a separate action, and Outlook has a card refresh mechanism for this. As a result, nobody clicks twice and everyone can see the status.

Phones also require basic access rules. The administrator should require multi-factor authentication, meaning a code or confirmation in an app in addition to the password. It is also worth deciding what happens to access when an employee loses their phone or leaves the company.

The simplest warnings do not need AI. The flow can work out “invoice without a purchase order” or “amount higher than in the order” from the data and show it on the card as a highlighted line. Such rules are predictable and easy to check.

AI is useful for long documents. It can prepare a two-sentence summary of a contract and point out clauses that differ from the template. The approver should still open the document, but knows what to look at.

Be careful with a “recommend approval” suggestion. With dozens of cards a day, it is easy to start clicking without reading, and the model can make mistakes. If you add one, show the reason next to it and leave the decision and the responsibility with a person.

Start with one type of document that often waits for sign-off, usually purchase invoices. Before you change anything, measure on the last 30–50 documents how many hours or days pass between the request and the decision. Without this, after the rollout you will have only impressions.

The plan might look like this:

Most problems with cards are not technical. They arise because someone designs the card from the system’s point of view rather than that of the person who has to make the decision. Typical mistakes: