Refresh & sharing
Refresh & sharing
Refresh — manual
Two affordances:
- ↻ per-widget — re-runs that widget’s SQL, persists
last_data_json, re-renders. - Refresh all on the dashboard header — parallel refresh of
every widget. Per-widget errors don’t fail the batch; the
failed widget shows
last_errorinline.
Refresh — programmatic
The bi.refresh_widget MCP tool. Locked contract:
tool: bi.refresh_widgetrequired cap: bi.readminted scope: bi:widget:refreshparams: widget_id: uuidreturns: data: { columns, rows, row_count, total, truncated } refreshed_at: datetime error: string | nullUse this for:
- External tooling triggering a refresh before reading
last_data_json. - Agents that need to pull live widget data.
- The Workbench’s “rerun against latest” flow.
The tool internally calls db.run_sql — same
AuthContext + validator + audit chain. You get the read-only
contract for free.
Refresh — scheduled (roadmap)
Auto-refresh on a cron is documented intent — not yet shipped.
When implemented, widgets will carry an optional refresh_cron
field and an APScheduler / CronJob worker will fire refreshes.
In the interim: open the dashboard manually, or hit
bi.refresh_widget from your own scheduler.
Sharing — public dashboards
Click Share on the dashboard header → generates a short-token read-only URL:
https://app.pollen8.ai/bi/share/aBcDeF12Anyone with the link can view the dashboard. They cannot:
- See the underlying SQL (only the rendered widgets).
- Edit, refresh, or delete.
- See any other dashboard or connection.
The share token is revocable — Revoke share invalidates it immediately; the URL 404s thereafter.
Sharing — internal
For per-user / per-role visibility within the tenant, use the dashboard settings drawer (Permissions tab). Defaults to “anyone with read on at least one of the widget connections.”
Snapshots (roadmap)
Snapshot dashboards — capture data + spec + layout at a point in time so a clinical report email links to a stable view — are roadmap. Not in v0.3.