TL;DR · Key Takeaways
- A dashboard is a live board of widgets, a view is a saved way of presenting one object type, and a report is a scheduled export of views. Different jobs, different audiences.
- Build small and role-scoped. One 6-widget board people open daily beats a 22-widget wall nobody reads. On one site, trimming a board from 22 to 6 widgets took load from 3.8 seconds to 0.9 and weekly opens from 6 to 40.
- Clone a predefined dashboard before you build from scratch, then strip what your team does not use. Starting empty wastes an afternoon.
- Widget interactions turn a flat board into a drill path: an Object List selection drives a Metric Chart and a View widget below it.
- In 9.1, dashboards moved to a relational store instead of a key-value one, so loading, creating and editing are faster. Faster access to clutter is still clutter, so prune anyway.
- A report only counts if someone acts on it. A scheduled PDF that lands in a folder nobody opens is not communication.
Most environments I walk into have too many dashboards, not too few. Somebody built forty of them over three years, each one made sense the day it was created, and now the team opens the same two and ignores the rest. The tooling is not the problem. VCF Operations gives you dashboards, views and reports that cover almost anything you need. The discipline is what is missing.
This part is about building the custom dashboards, views and reports that actually get used, and deleting the ones that do not. I will show you the three building blocks, how they fit together, and the numbers from a real cleanup where a bloated board went from ignored to the most-opened one on the site.
Three building blocks, three jobs
People blur dashboards, views and reports together, then wonder why their reports look nothing like their dashboards. They are different tools. A dashboard is a live workspace of widgets you look at on screen. A view is a saved presentation of one object type, a list or a trend or a distribution, that you can drop into a dashboard or schedule into a report. A report is a scheduled export, usually PDF or CSV, built from one or more views and delivered on a timetable. The table sorts out which one to reach for.
| Block | Job | Audience | Output |
|---|---|---|---|
| Dashboard | Live at-a-glance and drill down | Operators, on screen | Interactive board |
| View | Present one object type well | Reused inside boards and reports | List, trend, distribution |
| Report | Scheduled summary for people not watching | Managers, auditors | PDF or CSV on a timetable |
Clone before you build
Starting from a blank dashboard is the slow path. VCF Operations ships predefined dashboards for cluster health, capacity and the rest, and the fastest way to a good custom board is to clone one that is close, then remove what your team does not look at. You get sensible widgets and working interactions for free, and you spend your time cutting rather than assembling. Views work the same way. A predefined view is usually 80 percent of what you want, and editing the columns beats defining a view from nothing.
Widgets that talk to each other
A flat wall of widgets makes you scan. A board with interactions makes you drill. The pattern I use on almost every operational dashboard is a master-detail layout: an Object List widget at the top, and a Metric Chart plus a View widget below it, both configured to react to the selection above. Click a cluster in the list, and the chart shows its workload while the view lists its VMs and open alerts. One board answers three questions instead of one.
Access matters too. You can scope dashboards by role, so operators, capacity planners and managers each land on the board built for them instead of a shared everything-board. That scoping is also the honest way to keep boards small, because each audience only carries its own widgets.
Two smaller features do a lot of quiet work here. Badges colour an object by its health, risk or efficiency, so a List widget reads as a traffic-light at a glance instead of a wall of numbers you have to interpret. Filters change what a board is focused on without rebuilding it, so the same cluster health board can be pointed at one datacenter this minute and another the next. Between badges for the at-a-glance read and filters for the focus, you can keep one well-built board serving several situations rather than cloning it five times and maintaining all five. I lean on both before I ever add another widget, because the cheapest widget is the one you did not need.
Which dashboards actually get opened?
You can measure this, and you should. When I audit a site, I rank dashboards by how often they are opened, and the shape is always the same: two or three carry all the traffic and a long tail sits near zero. The chart below is from one such audit. The cluster health board was opened 640 times in a week. A legacy VM report board was opened 3 times. Guess which one somebody fought to keep.
Views carry the real information
The widget is the frame, the view is the picture. A List view ranks objects by the columns you pick. A Trend view plots a metric or a super metric over time with forecasting. A Distribution view buckets a population so you can see the shape of it, which is the one people underuse. Below is a distribution of VMs across a cluster by CPU workload band. It tells you at a glance that most VMs sit in the healthy middle and only a handful run hot, which is a very different message than a single average would give.
A worked cleanup
The site above had an executive dashboard with 22 widgets. It loaded in 3.8 seconds on the old key-value store, and people opened it 6 times a week, which for an exec board is close to never. We cloned it, kept the 6 widgets that mapped to questions leadership actually asked, wired two interactions so a region selection drove the charts, and scoped it to the manager role. After the 9.1 relational store and the trim, it loaded in 0.9 seconds and opens jumped to over 40 a week. Same data, a quarter of the widgets, seven times the traffic.
| Board | Widgets | Load 9.1 | Opens per week |
|---|---|---|---|
| Exec, before | 22 | 3.8s | 6 |
| Exec, after | 6 | 0.9s | 40+ |
| Cluster health | 8 | 1.0s | 640 |
| Legacy VM report | 14 | 2.1s | 3 |
Pick the right view type
Views come in more shapes than most people use, and reaching for the wrong one is why a board feels busy but says little. A List view is your default: rank objects by the columns that matter, sort, and colour by a badge. A Trend view plots a metric or a super metric over time, and it can carry a forecast so a capacity conversation stops being a guess. A Distribution view, the one I showed above, buckets a population so the shape is visible rather than an average that hides the outliers. A Text or Summary view is for context, a short block that tells the reader what they are looking at, which sounds trivial until you hand a board to someone who did not build it.
My habit is to decide the question first, then the view type. If the question is which objects are worst, that is a List sorted descending. If it is where is this heading, that is a Trend with a forecast. If it is how is the population spread, that is a Distribution. Choosing the view to fit the question keeps the board honest and keeps you from dropping four widgets where one would do.
Portable boards and shared building blocks
A dashboard you built by hand in one environment does not have to be rebuilt by hand in the next. Dashboards, views and reports can be exported and imported, and the cleaner path in 2026 is to package them into a management pack alongside the alerts and super metrics they depend on. That way the whole operational picture, the board plus the definitions behind it, travels as one unit and lands in the next environment already wired together. It is the same packaging I recommended for logs content, and the same reason applies: the goal is the whole team having the view, not one engineer holding it in a browser tab.
Portability also forces a useful discipline. When you have to package a board to move it, you notice the widgets that depend on objects the target environment does not have, and you trim them before they become broken tiles somewhere else. A board that exports cleanly is usually a board that was built cleanly. If you are moving content between sites as part of an upgrade, fold this into the plan I set out in the VCF 9.1 upgrade series rather than treating it as an afterthought.
Reports without the guilt folder
Reports are views on a schedule, exported to PDF or CSV and delivered by email or dropped to a share. They are the right tool for people who are not going to open a dashboard: a manager who wants a monthly capacity summary, an auditor who needs a compliance snapshot on a fixed date. The failure mode is the guilt folder, a share full of PDFs nobody opens, generated because generating them felt responsible. Before you schedule a report, name the person who will act on it. If you cannot, do not build it.
Because a report is built from views, the work you put into a good Distribution or Trend view pays off twice, once on the dashboard and once in the export. Build the view well, reuse it in both places, and keep the report to the two or three views that answer the recipient’s question.
Set the cadence to match the decision, not the calendar. A capacity summary that drives a monthly purchasing conversation belongs on a monthly schedule. A compliance snapshot an auditor expects on a fixed date belongs on that date and nowhere else. PDF is right when the recipient reads it as a document, CSV when they pull it into their own analysis. Match format to what the reader actually does with it, and the guilt folder never fills up.
Common questions
Clone or build from scratch?
Clone. A predefined dashboard or view gets you most of the way with working widgets and interactions. Cutting down is faster and safer than assembling from nothing.
How many dashboards is too many?
If a role has more boards than a person can name from memory, it has too many. Rank by opens, keep the ones with traffic and an owner, archive the rest.
Did 9.1 change how dashboards are stored?
Yes. They moved from a key-value store to a relational database, which makes loading, creating and editing noticeably faster. It does not make a cluttered board useful, so still prune.
What is a view good for that a widget is not?
A view is reusable and portable. Define it once and drop it into several dashboards and into reports. A widget lives on one board. Put the real presentation logic in the view.
Should everyone share one dashboard?
No. Scope by role. Operators, capacity planners and managers ask different questions, and a shared everything-board answers none of them well while loading slowly for all of them.
How do I stop dashboards multiplying again after a cleanup?
Make ownership a rule, not a suggestion. Every new board needs a named owner and a stated audience before it is saved, and a quick quarterly pass ranks by opens and archives the tail. Governance is boring and it is the only thing that keeps the count from creeping back to forty.
Do widget interactions slow a board down?
Not in any way you will feel on the 9.1 relational store. The cost of a board is the number and type of widgets, not whether they are wired together. A master-detail board with 6 interacting widgets loads faster than a flat one with 22, so interactions buy you clarity for free.
« Previous: Part 11 | VCF 9 Operations Complete Guide | Next: Part 13 »
References
- VCF Operations: Using Dashboards
- VCF Operations: Configuring Reports and Views
- Brock Peterson on VCF Operations 9.1 dashboards and views
About The Author
DrJha