BI Portal ships more than twenty widget types — bar, line, area, pie, funnel, scatter, waterfall, choropleth maps, KPI, gauge, treemap, grid, pivot table, filters, labels, images, buttons, page navigators, and shapes. The design mistake is not usually picking the wrong widget; it is picking a widget before deciding which question you are answering.
Match the question to the widget
- Trend over time → Line or Area, not Bar
- Share of total → Pie/Donut or Treemap, not a bare table
- Single headline number → KPI, with a mini sparkline if trend context helps
- Progress against a target → Gauge, with threshold zones configured
- Stage-by-stage drop-off → Funnel
- Row-level detail an analyst will export → Grid, or Pivot Table when grouping and measures need to be rearranged live
- Geographic distribution → Map Turkey (province/region) or Map World (country)
Configuration that actually determines correctness
Once the widget type is chosen, the result still depends on: the Data Source or Model bound to it, Live vs Offline mode (some restrictions apply per widget type — Dashboard-type pages allow data widgets in Offline only), the aggregation method (SUM/AVG/COUNT/MIN/MAX), and the maximum category/series limit. An empty chart after a correct type choice almost always traces back to one of these four, not the chart itself.
The Pivot Table exception
Pivot Table (Advanced Grid) is powerful enough that it deserves its own habit: save the view once before the first preview — the initial data fetch requires a saved view, and skipping that step looks identical to a broken widget.
Why it matters
Dashboards that mix chart types without a reason behind each one are hard to read and hard to trust. Deciding the question first, the widget second, keeps a BI Portal page closer to a report a manager will actually act on, instead of a wall of colorful boxes nobody opens twice.