Teams Task Module (Dialog) renders blank/black screen in a published app — works correctly in an unpublished/sideloaded app

Question

Teams Task Module (Dialog) renders blank/black screen in a published app — works correctly in an unpublished/sideloaded app

Nathan V 45

We have a custom Teams bot that opens a Task Module (dialog) via a task/fetch invoke, triggered by an Adaptive Card button click. In our unpublished, sideloaded test app, the Task Module opens and renders correctly. In our published production app (same manifest structure, same code, published through the Teams admin center), the identical Task Module flow results in a completely blank/black popup — no content renders, and no visible error is shown to the user. This reproduces in both Teams web and new Teams desktop.

Task Module invocation payload (identical logic in both environments, only the target URL differs per environment):
{
  "task": {
    "type": "continue",
    "value": {
      "title": "Create Article",
      "url": "https://<our-app-domain>/ticket-creation?user_id=<email>",
      "height": 580,
      "width": 720
    }
  }
}

manifest.json validDomains (production):
"validDomains": ["<our-app-domain>"]
The domain listed here exactly matches the host in the Task Module URL above.

Response headers returned by the Task Module URL:
content-type: text/html; charset=utf-8
content-security-policy: frame-ancestors teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us *.gov.teams.microsoft.us *.dod.teams.microsoft.us
access-control-allow-origin: *
- X-Frame-Options is not set.
- HTTP status: 200, full HTML returned (~14.5KB).

Diagnostics already performed:
1. Opening the exact Task Module URL directly in a browser (outside Teams) renders the form correctly — rules out a page-level/JS bug.
2. The domain is present in validDomains and matches the URL passed to the Task Module.
3. Content-Security-Policy: frame-ancestors explicitly allows teams.microsoft.com, *.teams.microsoft.com, and related Teams tenant domains.
4. No X-Frame-Options header is set that could conflict with the CSP.
5. Issue reproduces identically on Teams web and new Teams desktop — not a single-client bug.
6. The only functional difference between the working test app and the broken production app is that production has gone through app publishing/admin approval in Teams; the manifest structure, CSP, and validDomains configuration are otherwise equivalent between the two.

Question:
Does publishing a Teams app through the admin center change how Task Module iframes are sandboxed, validated against validDomains, or subject to additional tenant-level security/DLP policies that wouldn't apply to an unpublished/sideloaded app? Looking to understand what published-app-specific behavior could cause a Task Module to render blank while the identical configuration works when

0 comments

2 answers

Your answer

Answer 1

Hi @Nathan V

From my research, I found a scenario where a Task Module worked in one installation context but failed in another, even though validDomains was configured correctly. In that case, the root cause was that the same bot/app was installed simultaneously at both the organization level and as a personal/sideloaded app.

Teams did not pick up the updated manifest containing the correct validDomains until the app was completely removed and reinstalled. The suspected behavior is that Teams was resolving manifest/domain validation against a cached or conflicting installation record instead of reading the latest uploaded manifest.

Since publishing through the Admin Center is the one significant change in your environment, it may be worth checking:

Whether your tenant still has an older sideloaded version of the app installed.
Whether your test account currently has both: the original sideloaded version, and the organization-published version

installed at the same time.

Additionally, if the production app was published using Upload as a new app rather than Replace for an existing catalog entry, an App ID or manifest conflict could also occur. In some cases, this can cause manifest resolution or domain validation issues that only affect the published version, while the sideloaded version continues to work as expected.

It would be helpful to confirm:

Was the production app published using Upload or Replace?
If it was published using Upload, could you try performing a clean Replace deployment to rule out this possibility?

Finally, there is another possibility related to authentication.

I noticed that your Task Module URL includes: user_id=<email>. Because of that, it's worth checking whether the production environment triggers a different authentication flow compared to opening the page directly in a browser.

For example:

A silent SSO or token refresh process might occur inside the Task Module iframe.
That flow could redirect to a login page.
The login page itself may not allow iframe embedding, as many identity providers set frame-blocking security headers by default.

If that's happening, the result would typically be:

A blank or black iframe.
No obvious error message.
The request failing on the authentication provider's domain rather than your application's domain.

To verify this, I would recommend:

Open Dev Tools in Teams Desktop or Teams Web (F12) > Trigger the failing Task Module > Check the Network tab > Look for:

-Redirect chains.

-Blocked requests.

-Responses rejected due to frame restrictions.

-Requests that only appear when launched from Teams but not when opened directly in a browser.

This should help determine whether the issue is related to an installation/manifest conflict, or an authentication redirect occurring inside the iframe.

Please let me know if you find anything from those checks, especially whether both the sideloaded and org-published versions are installed simultaneously or whether the app was deployed using Upload versus Replace.

Michelle Nguyen 1,835 Reputation points Independent Advisor

2026-09-24T08:42:33.53+00:00

Hi @Nathan V

Thank you for the update.

Based on what you've confirmed, one line of investigation still worth checking is the webApplicationInfo configuration in the application manifest. Even if your Task Module page doesn't directly call getAuthToken(), Teams can still perform platform-level authentication or permission checks on the Microsoft Entra ID App Registration referenced by webApplicationInfo.id.

You could ask a Global Administrator to check the corresponding App Registration in the Microsoft Entra Admin Center and confirm that:

The App Registration is correctly linked to webApplicationInfo.id.

All necessary API permissions have been granted.

Admin consent has been granted to the tenant, especially if the permission list changed before or after the application was re-released under version 5.0.0.

If you have followed the steps above but still haven't encountered any problems, I recommend opening a Microsoft support ticket on Teams Admin Center so the support team can conduct a more thorough investigation.

I hope this information is helpful to you.

Answer 2

The documented Teams behavior in the provided material does not indicate that publishing through the Teams admin center changes dialog iframe sandboxing rules or introduces a separate published-app-only dialog rendering model.

The supported checks for this scenario are:

Verify the dialog URL domain is in the app manifest validDomains.
- Dialog URL domains must be included in validDomains.
- This applies to dialogs and tabs.
Verify CSP frame-ancestors includes the Microsoft 365 host domain.
- For apps that define CSP headers, the guidance is to add:
- https://*.cloud.microsoft
- Existing frame-ancestors values should be retained for backward compatibility.
Check runtime network behavior in Teams Developer Tools.
- The troubleshooting guidance recommends using the Network tab in Developer Tools in the Teams web client to inspect what is blocked or failing at runtime.
Confirm all runtime URLs and redirects stay on declared domains.
- For Teams tabs, URLs must use HTTPS and either match the settings page domain or be listed in validDomains.
- The authentication guidance also requires flows to start and end on a domain listed in validDomains.

Based on the available documentation, the most relevant published-vs-sideloaded explanation is not a documented publishing-state change, but a host/runtime framing issue:

missing https://*.cloud.microsoft in frame-ancestors
a runtime redirect or embedded resource landing on a domain not present in validDomains
a blocked network request visible only during in-Teams rendering

The context also shows that blank or generic load failures across clients are commonly associated with iframe security requirements, CSP framing headers, and undeclared runtime domains rather than app publication state itself.

References: