Building a management dashboard in Notion.

A useful dashboard comes down to three databases and four views. Here is how to build it, in what order, and above all what not to put in it.

Most Notion dashboards die the same way: they are too rich. Thirty indicators, six views per database, formulas nobody re-reads, and after two months nobody opens them. This tutorial describes the opposite.

What a dashboard should do, and should not do

A dashboard exists to trigger a decision. That is its only criterion of success. A figure that cannot change any decision has no place in it, however interesting it is.

The test is simple, and it eliminates most of the indicators one is tempted to display: if this number doubles tomorrow, what do you do differently? If the answer is “nothing”, the indicator goes.

Second principle: a dashboard is not a data entry tool. If it has to be filled in by hand every week, it will not be filled in. Anything that can be derived from data already present must be derived, not re-entered.

The structure: three databases, not thirty

It is the step one is tempted to skip and the only one that cannot be corrected afterwards without starting over.

The clients or accounts database

One row per entity you work with. Few properties: a name, a status, an owner. The temptation is to put turnover or the number of projects in it; you should not, those values are calculated from the other databases and a copied value always ends up diverging.

The projects or deals database

The heart of the system. One row per project, linked to a client, with a status, a start date, a target date and an owner. The status deserves a pause: three or four values are enough, and they must match the stages your team names spontaneously, not those of a template found online.

The tasks or time database

One row per unit of work, linked to a project. This is what feeds everything else. If you do not track time, this database still carries the tasks, and the dashboard will only lose the workload dimension.

The relations, which are the real subject

The three databases link together: task to project, project to client. It is that chain that lets information be surfaced without ever being re-entered. A classic mistake is to link tasks to clients directly as well, “to go faster”. That creates two paths to the same information, and they end up contradicting each other.

The rollups, which do the work

A rollup surfaces a value from the linked rows. On the projects database, a rollup counts unfinished tasks. On the clients database, a rollup counts active projects. Three or four rollups are enough to feed an entire dashboard, and they recalculate on their own.

The four views that genuinely serve a purpose

• What is late. A filter on a target date passed and a status not finished. It is the most consulted view and often the only one that triggers an action.
• What is coming this week. Same database, filter on the next seven days. It serves to prepare, not to observe.
• Workload per person. A grouping by owner, with the count of open tasks. It makes imbalance visible before it becomes a delay.
• Projects by status. A column view, which gives the overall state at a glance.

Four views, not fifteen. Every extra view divides attention and, in practice, nobody consults more than three regularly.

What to automate, and what not to

Notion can trigger actions, and it is tempting to wire everything up. Two automations almost always pay off, the others rarely.

The first: create the row from the place where the information actually arrives. A form on your site, a shared mailbox, a chat channel. As long as somebody has to copy things by hand, they will forget, and the database will be incomplete and therefore unusable.

The second: flag what tips into late, in the tool the person concerned already opens. An alert living only in Notion assumes somebody remembers to look.

Those two connections go through an automation platform. We compare the main ones in Make or Zapier, and the full approach is described on the process automation page.

What not to automate: cross-updating two databases in both directions. It looks elegant and it produces loops there is no getting out of.

The five mistakes we see most often

They look alike from one team to the next, and all of them are easier to correct before than after.

• Copying a value instead of linking it. The client’s name typed by hand into the tasks database, because it is quicker at the time. Six months later, three spellings coexist and no grouping works.
• Multiplying statuses. Nine values look more precise than four. In practice, nobody knows how to choose between “in progress” and “being handled”, both get filled in at random, and the view by status stops meaning anything.
• Creating one database per client. It is the most expensive mistake, because it cannot be repaired without redoing everything. One database per client rules out any cross-cutting view: you can no longer answer “what is late, across all clients”.
• Writing formulas you will no longer be able to read. A formula nested four levels deep works on the day it is written and becomes untouchable afterwards. When a formula runs over two lines, it is better to add an intermediate property, even if that is less elegant.
• Confusing the dashboard with the archive. Keeping the whole history in the same database slows the views down and drowns what is active. Anything finished more than a year ago moves to an archive database, consultable and out of the way.

What these five mistakes have in common is that none of them shows on the day it is made. They are all paid for at the same moment: when somebody asks a cross-cutting question and the structure cannot answer it.

Notion’s limits on this ground

Notion is excellent for a team dashboard and it reaches its ceiling sooner than people think. Three signals announce that ceiling.

Views handling several thousand rows become slow, and optimisation is no longer enough. Fine-grained permissions per row remain out of reach, which is a problem as soon as several clients must not see each other. And historical calculation, that is following the evolution of a figure over time, calls for contortions.

So the moment to leave is not a matter of taste. We set out those switching points in Monday or Notion, and the move to a dedicated sales tracking tool on the CRM integration page.