Can a notification-only bot handle Adaptive Card Universal Actions and a private account-linking prompt, or does this require a conversational bot?

Question

Can a notification-only bot handle Adaptive Card Universal Actions and a private account-linking prompt, or does this require a conversational bot?

Edgar Aguilar 25

Hi all,

We have a Teams app whose bot is notification-only ("isNotificationOnly": true in the manifest). It only posts proactive Adaptive Card notifications into team channels; users never message it. We're adding action buttons to those cards and want to confirm the approach is supported and store-compliant before building.

Intended interaction

The notification card carries one or two Action.Execute buttons. The card has no refresh property.
On click, our bot receives the adaptiveCard/action invoke. Server-side we resolve whether the clicking Teams user is linked to an account in our product.
If the user is not linked, we answer the invoke with an Adaptive Card response (statusCode 200, application/vnd.microsoft.card.adaptive) containing the original content plus an Action.OpenUrl button to our external account-linking page — intended as a prompt visible only to the user who clicked, without sending a DM.
The user links their account on our site, returns to the channel, and clicks the action again.
If the user is linked and authorized, we perform the action, post a reply in the thread (POST to the activity), and edit the original card to remove the button via a message update (PUT on the cached activityId) so the change is visible channel-wide.

No dialogs/task modules, no 1:1 DMs, no user messages to the bot — everything is a card click answered in the invoke response or a link out to our web app.

Questions

Does a bot marked isNotificationOnly: true still receive adaptiveCard/action invokes from its own cards in a team channel? The notification-only docs list only "users can't message or @mention the bot" as effects, but say nothing about card invokes.
The User Specific Views docs say the card returned in an adaptiveCard/action response is sent only to the client that requested it, and the toolkit docs say the response card "can only be updated for the interactor" by default. Does that also hold for a plain response card returned to an explicit button click on a card that has no refresh property? We intend to use that response as a private "link your account" prompt and want to be sure other channel members keep seeing the original card — or whether a refresh block with userIds is required to get that behavior.
Is this pattern acceptable under the Teams Store validation guidelines for a notification-only bot, or would using card actions / an external account-linking link require us to set isNotificationOnly: false and meet the conversational-bot requirements?

If there's a documented reference for any of these, pointers would be very welcome.

Thanks!

0 comments

2 answers

Your answer

Answer 1

Hi Edgar,

Thank you for the information.

Based on the current Microsoft Teams documentation, your proposed design is supported:

Setting isNotificationOnly: true prevents users from messaging or @mentioning the bot. Refer to Use Universal Actions for Adaptive Card - Teams, it doesn't indicate that it blocks adaptiveCard/action invoke activities generated when a user selects an Action.Execute button. The Action.Execute is documented to send an adaptiveCard/action invoke to the bot.
An Adaptive Card returned directly in response to the invoke is sent only to the client that requested it. Therefore, you can use the response card as a user-specific account-linking prompt while other channel members continue to see the original card. A refresh block is used for automatic refresh and broader persistent User Specific View scenarios. Also, it is not required solely for an explicit button-click response.
You can keep isNotificationOnly: true. Card actions do not automatically make the bot conversational. In the Teams Store Validation Guidelines - Teams, it also recommends that notification-only bots provide useful preview information and basic inline actions in their cards.

Please ensure the notification contains meaningful information, and the external-link button clearly states that it opens your website. Additionally, ensure that external account requirements and the linking process are disclosed in the app description and certification instructions. Then, you may proceed with this design while retaining isNotificationOnly: true.

However, the final approval will still be determined during the certification review process on the Microsoft Teams Store, as there is currently no official documentation providing a specific, definitive statement that precisely covers this deployment combination.

For references:

Hope this will help.

Hendrix 2,075 Reputation points Independent Advisor

2026-10-13T22:51:56.8333333+00:00

Good day Edgar

Just checking in to see if you've reviewed the proposed answer. If you have any other questions, please feel free to reach out again.

Answer 2

Hi Edgar,

Based on the current Teams manifest and Universal Actions documentation, your design is generally valid and doesn't require setting isNotificationOnly to false solely because the proactive cards contain Action.Execute buttons.

isNotificationOnly: true prevents users from sending free-form messages to or @mentioning the bot. An Action.Execute button generates an adaptiveCard/action invoke activity rather than a normal chat message, and the Universal Actions documentation doesn't identify notification-only bots as excluded from receiving those invokes.

For the private account-linking prompt, an Adaptive Card returned directly in the successful Action.Execute invoke response participates in a user-specific sequential workflow. The clicking user can receive the replacement card without changing the base channel card for other members. A refresh block isn't required for that explicit action response.

refresh.userIds is needed when you want automatic user-specific refresh, up-to-date personalized views or the user-specific state to be fetched again on another Teams client. Without refresh, don't assume that the private response shown on desktop will automatically be restored on mobile.

Your later explicit update of the original activity is separate: updating the cached channel activityId changes the shared base card for everyone, which is appropriate after the authorized operation completes.

From a Teams Store perspective, notification-only bots are supported, but the notification must provide useful information within Teams. A card that only says “click to view” and sends users outside Teams for all value can fail validation. For account linking, clearly state why linking is required, label the button to indicate that it opens your external site, provide clear sign-in/sign-up/sign-out guidance, declare the account dependency in the listing, and provide reviewers with a working test account and end-to-end instructions.

We recommend validating the combination in a sideloaded test app across Teams desktop, web and mobile because the notification-only documentation doesn't explicitly discuss Universal Actions. If adaptiveCard/action is suppressed only when isNotificationOnly is true, that would warrant an engineering investigation; otherwise the proposed design is consistent with the documented model.