How do you decide whether to allow AppSource custom visuals in Power BI reports across an organization?

## What the decision actually is Allowing marketplace visuals is a governance call with a real upside, and both extremes fail visibly. Ban everything and you get analysts rebuilding a Sankey diagram out of stacked bars, or exporting to another tool entirely. Allow everything and you get an estate where a dozen reports depend on a visual that stopped being maintained, renders blank after a platform update, and has no support path. ## Certified versus uncertified AppSource distinguishes **certified** custom visuals from the rest. Certification means the visual has passed a code review against a published requirement set and does not access external services or resources — no calling out to a third-party endpoint from inside your report. The practical consequence matters more than the badge: because certified visuals do not depend on outside calls, they are supported in scenarios that render the report outside a live browser session, such as export to PDF and PowerPoint and email subscriptions. Uncertified visuals may not render in those paths, which produces the discovery-at-the-worst-moment bug where the board pack exports with a blank rectangle where the chart was. That is the single most useful fact to bring to this question, and it reframes the discussion from "is it safe" to "will it still work in every channel my audience uses". ## The controls available At the tenant level, an administrator can allow or block custom visuals, and can restrict authors to certified visuals only. Separately, **organizational visuals** let an administrator deploy a specific visual — including a private, internally built one — into the tenant, where authors use it without going to AppSource. That is the pressure valve: the one uncertified visual you genuinely need becomes an admin-owned, version-pinned artifact rather than something every author downloads independently at a different version. Do not quote a specific settings path in an interview unless you are sure of the current one; these are renamed regularly, and the substance is the policy shape, not the click path. ## The evaluation checklist For a request to allow a specific visual, ask: - **Can a native visual do this?** Often the answer is yes at ninety percent fidelity, and ninety percent of a supported thing beats all of an unsupported one. - **Is it certified?** If not, is there a certified alternative, and what exactly does the uncertified one do that the alternative does not? - **Who maintains it, and how actively?** A visual from a vendor with a support contract is a different risk from a hobby project. - **Does it degrade required channels?** Export, subscriptions, mobile layout, accessibility — keyboard navigation and screen-reader support are frequently weaker in custom visuals than native ones — and features such as report page tooltips and drill-through, which some custom visuals do not support. - **What is the exit?** If the visual stops working, which reports break and what replaces it? A visual used in one exploratory report is a small bet; one baked into the standard executive template is a dependency. ## The security argument, stated correctly A weak candidate says custom visuals are a data-leak risk and stops there. Be precise. Row-level security and workspace permissions are enforced when the model answers the query — a visual receives only the rows the reader is entitled to, and no visual can widen that. The genuine concerns are narrower: an uncertified visual may contact an external service with the data it has legitimately been given, it is unreviewed third-party code in your rendering path, and licensing or support obligations may come attached. Certification exists precisely to address the first of those. ## Where organizations land A common, defensible policy: certified visuals allowed; a short, named list of uncertified ones approved case by case and deployed as organizational visuals; everything else blocked, with a request path that takes days rather than months so the policy does not push people to work around it. Pair it with a house template of native visuals covering the ordinary cases, so requests are genuinely exceptional. Review the approved list on a cadence, because the failure is rarely a bad decision at approval time — it is nobody noticing that a visual has been abandoned for two years. ## The judgment being tested There is no single right answer, which is the point. A strong response names the trade-off explicitly (capability now versus supportability later), distinguishes certified from uncertified on substance rather than trust, uses central deployment as the middle path, is correct about where the security boundary actually sits, and puts a review cycle on the decision instead of treating it as one-time.