Skip to main content

​
Theme

Settings → Theme sets the defaults every dashboard in the workspace inherits. Admins edit it.
The ordered palette charts draw from. A single-series chart uses the first color, and multi-series charts walk the list. You can add a color and remove one, between three and twelve. Reordering is not a control in the pane, so ask the agent to set the palette in the order you want.
Positive, negative, warning and muted. These are semantic rather than decorative. A KPI showing a decline picks up the negative color wherever it appears, so “good” and “bad” look the same across every dashboard.
Default date style, currency, locale and timezone. Number and date formatting across every widget follows these unless a widget explicitly says otherwise.
Theming is resolved when a chart renders rather than baked into the stored config. Changing the palette restyles existing dashboards immediately, with nothing re-fetched and nothing rebuilt.

​
Overriding per dashboard

A dashboard can override any of these for itself. Overrides are sparse, so you set only what differs and inherit the rest, and they ride along with version history. A restore brings back the dashboard’s appearance as well as its structure. The timezone default matters beyond appearance. It is the zone a new refresh schedule starts in.

​
Library

Settings → Library is the catalog of what a widget can be. It lists the built-in widget types alongside your workspace’s own visualizations, meaning authored code that draws the charts the built-in renderers cannot express, such as chord diagrams, beeswarms, ridgelines and waterfalls. Every member can see the Library, and authoring an entry is gated by neither plan nor admin role. It does need a builder seat, like any other authoring (Permissions). Editing or deleting somebody else’s entry is for its author or a workspace admin.

​
How library visualizations work

An entry holds the code. A widget points at an entry rather than containing a copy, which means:
  • fixing an entry fixes every dashboard using it;
  • a widget can never carry stale code that has drifted from the original;
  • an edit is immediate and wide. Every bound dashboard renders the new version at once, and the agent reports which dashboards just changed rather than asking first. Vistazo AI does ask before editing a bound entry. An external agent does not.
Entries render inside a sandbox and receive the resolved workspace theme, so a custom visualization matches the palette without being told about it. Entries are versioned, and a version can be restored. A widget always renders the entry’s current version, since there is no per-widget pinning. That is the point of the indirection. An entry is either private to its author or shared with the workspace. That governs discovery and reuse only, never rendering, so anyone who can see a dashboard can see the charts on it. New workspaces arrive with a couple of example entries so the feature is not an empty screen, and there is a gallery you can fork from. Copying an entry into your workspace gives you an editable copy rather than a live dependency on someone else’s.

​
Archiving, never deleting behind your back

An entry no live dashboard has used for 90 days is archived, meaning retired from listings and reversibly so. Editing it resets the clock, and it comes back out of the archive on its own if something binds it again. Nothing is ever auto-deleted. Deleting is manual, and it is refused while any widget still points at the entry, so a chart cannot lose its code underneath it.