# A Monday ops dashboard without a data team

> One sentence became a dashboard of saved read-only queries over the warehouse data. Every item was priced first, and the whole team refreshes it for free.

Source: https://triagic.com/use-cases/monday-dashboard-without-a-data-team

## The situation [#the-situation]

Monday, 08:00. Corvane Logistics runs four warehouses for fourteen brands, and the Monday review asks the same questions every week: are we shipping on time, what is stuck, is anything about to go wrong in the cold rooms. The answers are in the warehouse database and the event store. Getting them out has meant a spreadsheet somebody rebuilds by hand, or a request to a data team Corvane doesn't have.

Rhea runs operations and is the Triagic admin. Only admins build dashboards; everyone else opens them.

## What Triagic looked at [#what-triagic-looked-at]

On the desktop, **Dashboards → New dashboard**, she typed one sentence: *Monday floor review: on-time shipping by warehouse, orders past SLA, Reno pick rate, the Dallas freezers, inbound stuck at the dock, failed EDI syncs, invoices at risk.* Under **Use these data sources** she picked the organization's three: the warehouse Postgres, the MongoDB event store and the billing database.

**Propose a layout** showed its price, $0.31, before she pressed it. It read what those sources hold (tables, collections and a few sample records), read-only, and came back with nine items. Each one said what it shows, which source it uses and what it costs to build:

* On-time shipping by warehouse, last 48 hours: `orders` in Postgres.
* Orders past SLA and not shipped: `orders`.
* Pick rate per wave in Reno, units per hour: `pick_waves` in MongoDB.
* Freezer temperature, Dallas F1 against F2: `sensor_readings`.
* Inbound held at the dock: `purchase_orders`.
* Failed syncs (last hour): `edi_messages`.
* Invoices disputed or past due: the billing database.
* Orders by channel, and the top 10 SKUs by units.

She unticked the last two. The button read **Build 7 items** with the total on it, $0.84. Building picked one read-only query per item, ran each once to check the result had the right shape, and saved it. "Built" means the dashboard is now seven saved queries and how to draw each result.

## What it found [#what-it-found]

The first render did what the spreadsheet never did on a Monday morning:

* **Reno on-time: 68%.** Dallas, Allentown and Atlanta were all above 97%. Reno's pick rate fell from about 105 to about 60 units per hour starting Saturday morning, and 214 Reno orders were open past SLA.
* **Dallas F2 at -16.2°C**, with F1 beside it steady at -20.1°C. The line had been climbing for eight hours.
* **Four Larkspur Beauty purchase orders** waiting at the Allentown dock.

Each of those is now a question for the Console with a number already attached, not a theory.

## What changed [#what-changed]

The team opened the dashboard in the 09:00 review. Sam, the Reno floor supervisor, pressed **Refresh** three times during it. Opening, changing the range and refreshing run the saved queries directly from each person's own desktop over their own connections. No model is involved, nothing is charged and none of it shows on the Usage page. Results are cached on each desktop for 15 minutes, and the page syncs on that interval.

Sam is not on the Finance team, and the billing database is limited to Finance. On his screen, *Invoices disputed or past due* is a locked tile: the title, the source name and "You don't have access to this source." His desktop never received that tile's query.

Rhea built it once, for $1.15 including the proposal. Later in the week she pressed **Alert** on the failed-syncs tile, which is how the [03:12 page](/use-cases/number-went-bad-at-three-am) started. A dashboard holds up to 12 charts and KPIs; the rest of the limits are in the [dashboards docs](/docs/desktop/dashboards).