A Notion dashboard is one of the easiest things to build and one of the easiest to abandon. You spend a Sunday afternoon on it. Linked views, a few rollups, an emoji in the header. For two weeks you open it daily. Then weekly. Then you stop, and the work drifts back into your inbox and your head, which is where it was before.
The failure is rarely discipline, and it is rarely the layout. It is that the page was built to display a business rather than to run one. What follows is the difference between those two things, and the small set of decisions that keeps a dashboard in daily use past the first month.
Why most Notion dashboards become museums
Open an abandoned build and you will usually find the same three exhibits: a lifetime total, a chart, and a full table of everything. They tell you how much you have earned since the beginning, how many tasks exist, how many contacts you have collected. None of them tells you to do anything.
A museum is pleasant to walk through once. It gives you no reason to return on a Tuesday morning. And because nothing on the page is ever wrong or urgent, nothing on it ever prompts an edit, so the underlying data drifts. Within a month the Notion dashboard is quietly out of date, and you know it, which is why you stop opening it.
The second cause is scope. A page that summarises every database at once becomes long, and a long page is scrolled rather than read. If the top of the screen does not hold the answer, the page has already failed.
Showing data is not the same as prompting a decision
Put a blunt question to every block on the page. If this number changed, what would I do differently today? A lifetime revenue total survives that question badly. Invoices past their due date survives it well, because you chase them. Contacts with no interaction in thirty days survives it well, because you write to them.
This is why the useful views are almost always narrow and time-boxed. Not everything: the subset that has crossed a threshold. Not cumulative: this week. The page should read closer to a list of things asking for your attention than to a report.
It also means an empty view is a success, not a gap. When nothing is overdue, the overdue view shows nothing, and that emptiness is the most valuable thing on the screen. A total can never do that. It is always there, always slightly larger, always ignorable.
Which views earn a place on a Notion dashboard
A dashboard in Notion is not a database. It is an ordinary page holding linked views of databases that live elsewhere. You add one with Create linked view of database, point it at the source, and then configure it. That last step is the one people skip. A linked view with no filter and no sort is simply the database again, in a smaller box, and it inherits every row you have ever created.
Four view types cover almost everything a small operation needs. Table for anything you scan and edit in place: overdue invoices, follow-ups due, drafts waiting on you. Show three or four properties, not eleven.
Tableau, grouped by a status select, for work that moves through stages. You drag a card and the property updates, which is the only interface people reliably maintain. Calendar for items with a single date that must not collide, such as publication dates. Timeline, which needs a start and an end date property, for work that occupies a stretch rather than a moment.
Filters are where a view becomes useful. Notion’s date conditions are relative — the next week, the past month, today — so a view configured once stays correct without ever being edited. Combine a relative date with a status condition and you have the real substance of a Notion dashboard: work that is both unfinished and due.
Sorts matter more than they appear to. Eleven overdue invoices sorted oldest first tell you where to start. The same eleven in creation order tell you to read all eleven and decide again. Sorting is how a list becomes a queue.
Relations and rollups beat numbers you retype
The habit that separates a dashboard that stays true from one that decays is refusing to type any number that already exists somewhere else.
A relation property links a row in one database to rows in another: a client to their invoices, a campaign to its posts. A rollup then reads across that link and calculates — sum the invoice totals, count the unfinished pieces, show the latest interaction date. The official help pages on relations and rollups list the calculations available.
A retyped figure is correct on the day you type it and wrong shortly afterwards, silently. A rollup cannot go stale, because it is not stored anywhere; it is read each time. That is worth a few minutes of setup even for a figure you only consult once a month.
Rollups also make good filters. A latest interaction rollup on a client row, filtered to before one month ago, produces a list of relationships going cold. That is a decision generated by two properties and no manual review at all.
Formulas, used with restraint
Formulas earn their place when they turn several fields into one judgement: days until due, margin per project, whether a piece has everything it needs before it can be scheduled. Two cautions, both learned the slow way.
First, be explicit about what a formula returns. A formula whose result type is left ambiguous behaves unpredictably when you try to filter or sort a view by it, and the view will often show every row without reporting an error. Second, prefer a real property to a clever formula wherever the two compete. A date property filtered relatively will still be right next year. A formula written around this month’s data usually will not.
If you cannot explain a formula to yourself three months later, nobody will maintain it. Delete it and use a select.
The weekly ritual that keeps a Notion dashboard alive
No structure survives without a habit attached to it. Twenty minutes, the same slot every week. Friday afternoon or Monday morning matters far less than the repetition. The dashboard is the agenda for that meeting with yourself, and the only reason its views need to be correct.
Three passes. Clear the action views: chase what is overdue, write to the cold contacts, move or drop whatever has slipped. Then look at what has not moved, using a last edited more than fourteen days ago filter, which is unflattering and useful in equal measure. Then close the loop, so that anything you decided during the review becomes a row rather than a note in your head.
The ritual doubles as maintenance. Views nobody opened in four weeks get deleted. Properties nobody fills get deleted. A Notion dashboard that is edited every week stays honest; one that is only ever read drifts away from the business it describes.
What a Notion dashboard should leave out
Vanity totals first. Lifetime revenue, total contacts, all-time published count: pleasant, inert. If you want one for morale, put it at the bottom where it belongs.
Second, duplication. If the same list appears twice with slightly different filters, one of them will fall out of date in your head, and you will act on the wrong one at the worst moment.
Third, everything added because it was possible. Buttons that create a pre-filled row are genuinely useful. So are database templates, and number properties shown as a bar. Each is also one more thing to maintain. Add them after the page has survived a month, not before it has survived a week.
The finished page should fit on roughly one screen. Five or six views. Anything below the fold is being kept for reasons other than use.
Aller plus loin
Every Notion dashboard sits on databases that were designed for something else first, and that layer is where most of the work is. If you would rather start from a structure that already holds together, our Lightweight CRM covers contacts, a drag-and-drop pipeline and an interaction log, while the Cashflow Ledger tracks income, expenses and invoices with late-payment alerts. Both belong to the wider systèmes Notion collection. If you would rather build it yourself, our walkthrough on building a simple CRM in Notion sets out the database layer this article assumes.
Questions fréquentes
Should a Notion dashboard be its own page, or live inside a database?
Its own page. Databases are for records; the dashboard is a reading surface built from linked views of them. Keeping the two separate means you can rebuild the page, reorder it or throw it away without touching a single row of data.
How many views is too many?
If you cannot say out loud what decision each view supports, you have too many. In practice five or six is comfortable and ten is a page nobody finishes reading. The count matters less than the test: a view that has never once changed what you did that day should be removed.
Do I need a paid Notion plan for this?
No. Databases, every view type, filters, sorts, relations, rollups and formulas all work on the free plan. Paid tiers add collaboration, permissions and administration, which matter for a team rather than for database capability. One person, or one person and a client, fits comfortably inside the free plan.
What if the dashboard is for a client rather than for me?
Then filtering is not enough. A shared view still exposes the database behind it, so a client-facing page needs its own database or a duplicate you maintain deliberately. Decide that before you build, because retrofitting access rules onto a page that was designed for one reader is slow and error-prone.