Is there any recent change in Teams that introduces stricter validation for InvokeResponse payloads or Adaptive Card submissions?

Question

Adaptive Card submit actions (Action.Submit) trigger the bot successfully, but no response is rendered in the Teams UI.

When a user clicks a submit button on an Adaptive Card:

• The bot receives the invoke activity correctly
• Backend logic executes without errors
• A valid InvokeResponse (HTTP 200) is returned

However, in the Teams client (desktop and web), the UI either:

• Shows a generic error: “Something went wrong. Please try again.”, or
• Does nothing (no card update, no message, no task module)

This behavior started recently without any changes to:

• Bot code
• App manifest
• Permissions or authentication setup

The same implementation was previously working as expected.

We are handling the invoke using standard methods such as:

• OnInvokeActivityAsync
• OnTeamsTaskModuleSubmitAsync

The response structure follows documented examples for task responses.

Is there any recent change in Teams that introduces stricter validation for InvokeResponse payloads or Adaptive Card submissions?

Answer 1

Hello Hardeman Saul,
While there has been no officially documented change in the Microsoft Teams SDK, app manifest, or Adaptive Card schema introducing new mandatory fields for InvokeResponse, recent updates to the Teams desktop and web clients (late 2025–2026) have begun enforcing stricter client‑side validation of invoke responses. This means that even when an Adaptive Card Action.Submit correctly triggers the bot, executes backend logic successfully, and returns an HTTP 200 response, the Teams UI may still show a generic “Something went wrong. Please try again.” or render nothing if the response body is delayed, incomplete, or not in the exact structure expected by the client.
Additionally, Teams now effectively enforces a ~5‑second response window for invoke activities—responses returned after this window (due to long processing or cold starts in consumption‑based hosting plans) may be silently ignored by the client despite being valid—resulting in the recent behavior where previously working implementations no longer update cards or open task modules in the UI.

Reference Document:
https://learn.microsoft.com/en-us/microsoftteams/platform/messaging-extensions/how-to/action-commands/respond-to-task-module-submit?tabs=dotnet%2Cdotnet-1

Answer 2

Hi Hardeman Saul

Based on available information, we cannot confirm this as an officially documented change, there is no published changelog or Microsoft announcement stating that stricter validation has been introduced for InvokeResponse payloads or Action.Submit submissions.

From my perspective view in this situation, you can try steps below to see if it can help you:

Step 1: If your bot is hosted on a consumption-based or scale-to-zero plan (Azure App Service, Functions), a cold start alone can push response time past 5 seconds before a single line of your handler runs. Enable always-on or add a warm-up probe before refactoring any invoke logic, this is the most underdiagnosed root cause of this exact symptom.

Step 2: Capture the activity reference before any async work, return the invoke response immediately, then update the original card once processing completes:

protected override async Task<InvokeResponse> OnInvokeActivityAsync(
    ITurnContext<IInvokeActivity> turnContext,
    CancellationToken cancellationToken)
{
    // Capture before any async work
    var convRef = turnContext.Activity.GetConversationReference();
    var activityId = turnContext.Activity.ReplyToId;

    // Fire long-running work off the invoke thread
    _ = Task.Run(() => DoWorkAndUpdateCard(convRef, activityId));

    // Return within the 5-second window
    return new InvokeResponse
    {
        Status = 200,
        Body = new
        {
            statusCode = 200,
            type = "application/vnd.microsoft.activity.message",
            value = "Processing..."
        }
    };
}

Step 3: Confirm Content-Type: application/json is explicitly set. A bare HTTP 200 with no body, or a card not wrapped in the envelope, causes silent failure. For task/submit flows:

{
  "task": {
    "type": "message",
    "value": "Submitted successfully."
  }
}

Step 4: Plan migration to Action.Execute

Action.Submit carries ongoing risk with each Teams update. If this bot is actively maintained, scheduling a migration to Action.Execute (Universal Actions, card schema v1.5+) will eliminate this class of failure permanently. Use Action.Submit as a fallback property during transition for older clients.

Hope my answer will help you.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

No information is provided about any recent Teams platform change that introduces stricter validation for InvokeResponse payloads or Adaptive Card submissions.

The available guidance instead focuses on how Adaptive Card submit actions and dialog submissions are expected to behave and how to avoid common pitfalls:

1. Action.Submit behavior and routing
   • In Teams, Action.Submit on Adaptive Cards behaves as a Bot Framework invoke action: the submit triggers an invoke call to the bot, and the bot receives the payload with all input values.
   • For message extensions and dialogs, the platform sends specific invoke activities:
     • For message extensions: Action.Submit sends an invoke with name composeExtensions and the usual payload.
     • For conversation cards: Action.Submit results in a message activity with name onCardButtonClicked.
     • For task modules (dialogs) where TaskInfo.card is an Adaptive Card, any Action.Submit sends a task/submit message to the bot.
   • These behaviors are documented as the expected, stable model.
2. Validation and what gets submitted
   • Input validation is performed when the user selects an Action.Submit button.
   • Only inputs on:
     1. The same card as the Action.Submit, and
     2. Any parent cards (for Action.ShowCard hierarchies) are validated and submitted.
   • Inputs on child or sibling cards are not validated or submitted. This behavior applies to renderer versions 2.0 and later for all schema versions.
   • If validation fails, the submit is blocked and error messages are shown on the card; the bot does not receive the submit.
3. Conditional enablement of buttons
   • The conditionallyEnabled property can be used with Action.Submit and Action.Execute to keep buttons disabled until required inputs change.
   • If isEnabled is false, the action is disabled regardless of input values.
   • Misconfiguration here can prevent the submit from firing at all, but it does not change how a valid InvokeResponse is processed once sent.
4. Universal Actions and Action.Execute
   • Action.Execute is introduced as a universal action model across Teams and Outlook, but it is not a replacement for Action.Submit in all scenarios.
   • For scenarios like messaging extensions or link unfurling, Action.Submit remains required.
   • Action.Execute can return an updated Adaptive Card as the response to the invoke, but this is an additive model, not documented as a breaking change to existing Action.Submit flows.
5. Known issues and mitigations around submit behavior
   • For agents and Adaptive Cards in web chat experiences, stale or multiple submits can cause unexpected behavior. Recommended mitigations include:
     • Using unique identifiers in Action.Submit.data (for example, actionSubmitId) so the backend can distinguish which card/action was invoked.
     • Disabling submit buttons after the first click or mutating the DOM to prevent duplicate submissions.
   • In Copilot Studio scenarios, a submit action can inadvertently trigger logic on every submit if not scoped correctly; adding the appropriate submit-related metadata (such as an identifier or associated input configuration) is required to ensure only the intended button triggers the logic.
6. Dialog (task module) submit behavior
   • For dialogs using TaskInfo.card (Adaptive Card), when the user selects any Action.Submit button, the filled card body is sent to the bot via a task/submit message.
   • The documented behavior is that the bot receives this payload and can respond with supported task responses (card response, another dialog, bot with Adaptive Card, or no response) depending on the commandContext.

Within the provided material, there is no mention of a new or recent change in Teams that would tighten validation of InvokeResponse payloads or Adaptive Card submissions in a way that matches the described regression (invoke received, backend succeeds, HTTP 200 returned, but no UI update and a generic error).

---

References:

• Card actions
• Respond to the dialog submit action
• Use dialogs with bots
• Enhance user experiences with Universal Actions for Adaptive Cards
• Universal Action Model
• Input Validation
• Ask with Adaptive Cards
• Adaptive card triggers on every submit action - Microsoft Q&A