Custom Power-Up connector iframe never loads on a board — reproducible with two independent fresh re

[Villy]

Hi everyone,

I'm building a custom (private, unlisted) Power-Up for internal use on my company's Trello Workspace, and I've run into a bug where the Power-Up's connector iframe never loads in the Trello web client, despite everything being correctly configured on the server side. Since Atlassian support isn't available for Free-plan accounts, I'm hoping someone here — ideally someone who's worked on Power-Up development, or from the Trello team who monitors this forum — has seen this before or can point me in the right direction.

Account and environment

• Account: salvitabulgaria
• Workspace: Salvita Bulgaria (salvitateam1, id 6331423ce094a3016b9a7918), Free plan
• Test board: "Test Board" (id 6a8193949dc5f545711941aa, https://trello.com/b/0GCzOT3g/test-board)
• Plugin IDs tested: 6a81a451987e63609644065d (deleted), 6a81bc178cafb54c7151635c (current)

Summary

A custom Power-Up, correctly registered and enabled on a board, never has its connector iframe loaded by the Trello web client — no network request to the connector URL is ever made, no iframe element is created in the DOM, and none of its registered capabilities (card-badges, card-buttons, card-back-section) ever render. This happens with zero JavaScript errors, on two completely independent, freshly-created Power-Up registrations. By contrast, an official "Made by Trello" Power-Up ("Card Aging") added to the exact same board in the same browser session renders and works immediately with no configuration beyond clicking "Add."

Steps to reproduce

1. Create a new custom Power-Up at https://trello.com/power-ups/admin/new under Workspace "Salvita Bulgaria."
2. Set the Iframe connector URL to a valid HTTPS page (an HTML wrapper that loads the Trello power-up.min.js script plus our connector script — verified reachable via curl with clean response headers, no X-Frame-Options/CSP present).
3. Enable capabilities: card-back-section, card-badges, card-buttons.
4. On the "Privacy and compliance" tab, answer "Does your Power-Up store any Trello user personal data?" = No, and Save (confirmed persisted — the board's Power-Up detail page shows "is in compliance with Trello's data and privacy practices").
5. Enable the Power-Up on the test board (confirmed via the board's boardPlugins REST endpoint — the plugin appears listed with promotional:false, and the board's Power-Ups > Enabled tab shows it with a working Settings gear).
6. Open any real, non-template card on that board.

Expected: the connector iframe loads, and card-badges/card-buttons/card-back-section render according to the registered capabilities.

Actual: nothing renders at all. No entry appears in the card's "Power-ups" tray. Zero network requests to the connector URL (confirmed via DevTools Network panel, filtered by the connector's domain — completely absent, not even a failed/blocked entry). Zero iframe elements matching the connector URL anywhere in the DOM (checked via a querySelectorAll scan for iframes at both board view and card-detail view). The browser console repeatedly logs a warning from Trello's own ltp.[hash].js asset file:

"board plugins are undefined"

This warning fires 4 times on board load and 4 more times on every card open, consistently, in every test.

What I've ruled out

• Wrong connector URL format (initially pointed directly at the connector script instead of the required HTML wrapper page — fixed).
• ngrok free-tier browser-interstitial silently blocking a hidden iframe (switched to Cloudflare Tunnel, which has no such interstitial — confirmed via the tunnel's own inspector logs showing zero real hits regardless).
• The Power-Up admin UI's "Save" button not actually persisting the connector URL (verified via the plugin REST endpoint after a hard reload — the value is correctly saved server-side).
• A missing/null "Privacy and compliance" answer (was null initially — fixed, verified persisted, and the board's Power-Up page now shows the compliance-confirmed message).
• The specific plugin registration being corrupted or "stuck": deleted the original Power-Up entirely and created a brand-new one from scratch (different idPlugin, different API key/secret) with capabilities, connector URL, and privacy answer all set correctly from the start. Identical failure.
• Workspace/board-level Power-Up restrictions: this Workspace is on the Free plan, which has no admin-level Power-Up allowlist/restriction settings available (confirmed in Workspace Settings — those controls are shown as Premium-gated and inactive).
• Board-level feature gating: the board's premiumFeatures list includes "plugins" (confirmed via the board REST endpoint with fields=all).
• The legacy board.powerUps field (as opposed to boardPlugins): confirmed empty even for the working Card Aging Power-Up, so this field is unrelated/vestigial for the current boardPlugins-based system and not the mechanism the client actually reads from.
• Browser/session/profile-specific caching: reproduced independently by the board owner in a genuinely fresh Incognito window with no shared session or extensions.
• Trello's "Labs" experimental feature flags: only "Rovo Chat" is listed there — nothing related to Power-Up development.
• CSP / X-Frame-Options headers on the connector: checked directly via curl on both the public tunnel URL and the origin server — no X-Frame-Options header and no Content-Security-Policy header present at all. Framing is not being blocked at the header level (and in any case, the client never even attempts to create the iframe, so it never reaches the point where CSP would matter).
• "Copy Board" as a fix for possibly-corrupted board metadata: copied the test board within the same Workspace, keeping cards. The copy correctly carried over both boardPlugins entries (Card Aging + our custom plugin). On the fresh copy, Card Aging still rendered instantly and correctly; our custom Power-Up still never attempted to load — same warning, zero network requests.
• "Remove personal settings" as a way to clear a stuck authorization token: this option isn't available for our Power-Up at all — its Settings menu only offers "Disable." (Per Trello's own docs, "Remove personal settings" only appears for Power-Ups using a personal-authorization capability, which ours doesn't use.)
• Testing on a different Workspace to isolate whether this is Workspace-specific: not possible to test as a private/unlisted Power-Up — Trello returns 403 Forbidden when attempting to enable it on a board outside its owning Workspace, and it doesn't even appear under that board's Power-Ups > Custom tab. This check is blocked by Trello's own design, not by whatever is causing the bug.

Control test proving this is specific to custom Power-Ups

I added the official "Made by Trello" Power-Up "Card Aging" to the same test board, in the same browser session, immediately after failing to get our custom Power-Up to load. Card Aging rendered correctly and instantly (its "Last updated" badge appeared on the card) with zero configuration beyond clicking "Add." This isolates the failure specifically to custom/private Power-Ups — the board, account, and browser session are otherwise fully capable of loading and rendering Power-Up UI without any issue.

Net result: the one variable that consistently correlates with the failure, after ruling out everything else through direct testing, is "custom/private Power-Up" versus "official Made-by-Trello Power-Up."

Evidence available on request

I have a sanitized HAR export (cookies/auth stripped) captured from a fresh page load of a card on the test board, showing the full set of network requests the Trello client makes on card open — notably, no request to our connector domain appears anywhere in it, which is the core of the bug. I haven't attached it here, but I'm happy to send it directly to anyone looking into this, or share a link separately.

Question for the community

Has anyone run into a Power-Up's boardPlugins entry being visible via direct REST API calls but never surfaced to the web client's plugin-loading logic — i.e. the "board plugins are undefined" console warning? Is there some additional registration step or account-level flag for custom Power-Ups on Free-plan Workspaces that I might be missing? Any pointers — even "check X" — would be a huge help at this point, since I've exhausted everything I can test from the outside.

Thanks!
Villy 

[Gabriela - LeanZero]

Hi @Villy, that warning isn't coming from your Power-Up. "board plugins are undefined" appears zero times in power-up.js and zero times in power-up.min.js. It ships inside Trello's own BoardHeaderButlerButtonsModernized component as the value of an error field the hook hands to console.warn, and what sets it is the board's plugins collection reading as undefined in the client's own state. So it's the client telling you it has no board plugins, which is your symptom rather than a second fault.

One aside on that: your console attributed the line to ltp, and the string isn't in today's ltp build at all, so the frame has moved between deploys.

The part that answers your actual question sits next to it. The loader doesn't read the REST boardPlugins collection you verified. Plugins/loadPlugin.ts fires a GraphQL query called BoardEnabledPlugins against board plugins(filter: enabled), cache-first, selecting id, capabilities, iframeConnectorUrl, listing, moderatedState, public, idOrganizationOwner, name and icon. When your id isn't resolvable after that query it throws "plugin not available to board". Grep your console for that. The board field carries an @client directive, so it resolves out of the Apollo cache and there'll be no network request named BoardEnabledPlugins to find.

Then look at moderatedState in that selection. Atlassian stripped it from the REST plugin response in 2019, in their words "The following fields have been removed: apiKey, author, idAgreement, moderatedState, privacyUrl, supportEmail, tags, usageBrackets", so the loader reads a field your REST checks could not have shown you. The Power-Up security page says "A moderated Power-Up will remain enabled on all boards on which it is enabled, but it will never be initialized." That's your symptom in Atlassian's own sentence. I doubt a brand-new idPlugin inherits a flag like that, so treat it as the state to have someone read for you, not as a diagnosis.

Your read on support is half right. The Trello product portal is subscription-only, "Only Trello users with an active subscription can submit support tickets". The developer desk is separate and Trello's own dev docs point at it, go.trello.com/dev-support, landing on developer.atlassian.com/support. Its entitlement row names no plan, only "Partners and developers looking to extend the functionality of Atlassian apps". In July a developer hit a Trello-wide Power-Up iframe regression, got no forum reply, raised ECOHELP-148080 as a P1, and Trello confirmed and fixed it. I haven't tried that desk from a Free workspace with an unlisted app, and the packaging line does read "a valid customer license or any tier of the Marketplace Partner Program", so that's where I'd expect friction. Send them the HAR.

Atlassian's Power-Up guide will send you to the developer community, and I'd not lean on it. Of the 18 Trello topics opened there during 2026, 14 still have no reply of any kind, and I didn't find an Atlassian staff reply on any of them. Topic 99226 is the closest to your shape, a required Trello script asset for which no request is ever made, and it got nothing.