Guide section 19 of 31
Power BI Restrictions Designers Must Know
| Restriction | Why | UX consequence | Recommended workaround | Native workaround available? |
|---|---|---|---|---|
| No general CSS/DOM layout engine | Power BI visuals expose defined formatting/property controls rather than arbitrary CSS. | Pixel-perfect web designs may not map cleanly. | Design within the format pane/theme capabilities. | Yes — use native formatting/theme/layout. |
| No automatic Figma-token synchronization | Figma variables and Power BI themes are separate systems. | Token changes can drift. | Govern a mapping and regenerate/update theme/configuration deliberately. | Partly — theme JSON and reusable config. |
| Mostly fixed report canvas | Desktop report pages do not behave like breakpoint-driven app layouts. | Design must account for scale and viewport. | Choose target canvas and create mobile layout separately. | Yes — page view + mobile layout. |
| Visual-specific formatting limits | Different visuals support different properties. | Uniform styling may not be possible everywhere. | Use approved configurations and accept native differences. | Usually. |
| Interaction set is constrained | Cross-filter/highlight, drill, bookmarks, navigation, parameters etc. are predefined mechanisms. | Arbitrary prototype behavior may be impossible. | Map every interaction during design. | Yes, if the needed behavior exists natively. |
| Bookmarks can become brittle | Bookmarks save state and can overlap filters/visibility/drill. | Application-style state machines are hard to maintain. | Keep bookmark groups small/independent; prefer parameters/navigators where suitable. | Yes. |
| Tooltips are not full interactive panels | Report tooltips are for contextual display, not complex interaction. | Do not put required controls or critical content there. | Use drillthrough/detail page for interactive depth. | Yes — drillthrough. |
| Tables/matrices are not web data grids | Native behavior, scrolling, hierarchy and export differ from custom frontend grids. | Do not design unsupported pagination/editing patterns. | Use native Table/Matrix configuration where possible. | Yes, within native capabilities. |
| Custom visuals add governance/performance/accessibility risk | They have separate lifecycle and capabilities. | More testing and maintenance. | Require analytical need + approval + fallback decision. | Sometimes — use native alternative first. |
| Print is not automatically pixel-perfect | Interactive canvas and print/PDF goals differ. | A good screen may not be a good A4 page. | Create/test print composition or use paginated report. | Yes — paginated reporting for precise hard-page output. |
| Mobile is a separate composition | Phone view is optimized separately. | Desktop layout should not simply shrink. | Design mobile when mobile is in scope. | Yes — mobile layout. |
| Hidden synced filters can surprise | Filter context may persist without visible slicer. | Users may misinterpret results. | Expose persistent context/active filters. | Yes — visible context/filter summary. |
| Q&A is deprecating | Legacy Q&A is scheduled to go away in Dec 2026. | Do not make it a strategic UX dependency. | Do not standardize new Q&A page patterns; evaluate current alternatives separately. | No long-term Q&A workaround as a standard. |
| Bing Map/Filled Map are on deprecation path | Microsoft is moving map direction to Azure Maps. | New designs should not depend on legacy maps. | Prefer Azure Maps and migrate legacy visuals. | Yes — Azure Maps. |