Data Consumption - Dashboards, Queries, Oh My

The Problem

Many analytics teams today are plagued by the too-many-dashboards problem: they build dashboards, and no one uses them.

Dashboards are often artisanal works: carefully prepared, aggregated for performance, and refined through multiple rounds of stakeholder feedback. To make them work for more than one stakeholder, teams add a growing list of filters and customizations. These additions slowly undermine the dashboard's performance and its value for the original use case, until the cycle starts over.

And that's if they even get used—sometimes a dashboard is requested, and the business has moved on by the time it arrives.

Tips

This is also the appeal of conversational analytics: if you can give an executive the dashboard they want during the meeting—or before it— you never receive the request to build it later.

What's Better?

Dashboards should be cheap and disposable. Queries should be too. They need to be built and customized incredibly quickly; everyone should be able to get exactly the view they want.

Do Agents Solve This?

To some degree, agentic BI—"fetch the data and build me this bespoke view"—is the solution. Without being bottlenecked by a single analyst working in a BI tool, everyone can get exactly the view they want. But this only shifts the bottleneck: it is no longer the consumption layer, but our shared understanding of reality.

That's a classic reason for creating dashboards: for this project and this metric, let's have a single source of truth.

The Trilogy Proposal

You can have your cake and eat it too. Dashboards can be disposable, but your semantic layer needs to live forever. We're not unique in proposing a shared context layer as the solution, but we think we make the progression from seamless personal customization to shared context easier than anyone.

A Trilogy data consumption ecosystem is layered:

At the top are dashboards, queries, and chats. They move fast, are fit for purpose, and can be retired quickly.
Below are team- or project-specific model files. They contain shared calculations, evolve incrementally through version control, and have more governance.
At the bottom are core data source files. These change most slowly, contain core metrics, and may be owned by a central team.

You can add more groupings as you scale, creating a classic federated data mesh with first-class support.

What Is a Warehouse?

A useful—if overly simplistic—view of a warehouse is that it contains cached computations derived from raw data: turtles all the way down.

From this perspective, a consistent conceptual layer—one that recognizes concepts as the same as they move through tables, just with some temporal lag—is a powerful simplifying force. You don't have to guess whether two assets represent the same concept or which new source should power a pipeline or dashboard; the consumption layer responds flexibly as the semantic mapping changes.

Let's Make It Concrete

Let's play out a classic data warehouse boogeyman: updating an executive dashboard to use a new, more comprehensive source.

Clone the original model file.
Update the new model file's data sources to map to your new physical tables.
Clone the dashboard and point its import to your new model.
QA the dashboards side by side.
Update the original dashboard to import your new model.

That's it! The last step - a one line change - is easy. You don't need to change any queries; the entire operation is driven by metadata.

Ready to Try It?

Grab one of our community data models and see how fast you can build a dashboard today in Trilogy Studio.