Every data-bound widget in BI Portal reads from one of two modes, and the choice is not cosmetic — it decides where the numbers actually come from. Live fetches from the source (often SAP) at the moment the page runs. Offline reads a cache filled ahead of time by a scheduled refresh job.
Rules that are easy to forget
- File-type sources have no Live mode at all — cache is the only option
- Dashboard-type views restrict data widgets to Offline only; filter widgets are usually exempt
- Live Selection Filter widgets pair with Live mode; Result Filter widgets apply WHERE-style logic against the Offline cache
- Live connections may enforce a row limit — large results belong in Offline, not a Live query pushed past its limit
- An empty Offline widget almost always means the refresh job never ran or failed — that is a job-log question, not a widget question
A simple decision rule
- Does the user need to change plant, date range, or company code every time they open the page? → Live
- Is this a KPI board reviewed every morning off yesterday's close? → Offline, with a nightly refresh job
- Is it a personal dashboard someone opens dozens of times a day? → Dashboard type + Offline, so it opens instantly instead of re-querying SAP on every click
Why it matters
Teams that default everything to Live end up hammering SAP with repeated queries and hitting row limits on exactly the reports leadership checks most often. Teams that default everything to Offline lose the ability to slice by a value nobody cached. Choosing per-widget, deliberately, is what keeps both SAP load and dashboard freshness under control at the same time.