Notion Dashboards: Der vollständige Guide für Teams

Notion Dashboards entscheiden, ob dein Team-Setup funktioniert oder nicht. Jedes gute System braucht sie – aber die meisten Teams überspringen sie komplett oder bauen überfüllte Mega-Seiten, die niemand freiwillig öffnet. In diesem Guide lernst du das Framework, das wir mit unseren Consulting-Kunden nutzen: wo Dashboards in deiner Workspace-Architektur ihren Platz haben, was draufgehört – und wie du die drei Dashboard-Archetypen Schritt für Schritt aufbaust, inklusive der neuen Tabs und Dashboard-Ansicht von Notion.

Warum sind Notion Dashboards wichtig? Front End vs. Back End

Dashboards sind das Front End deines Notion Workspace – die Seiten, auf denen dein Team tatsächlich arbeitet. Deine Daten liegen im Back End: eine zentrale Datenbank pro Objekt (Aufgaben, Projekte, Kunden), ordentlich strukturiert, aber nie direkt bearbeitet.

Die Trennung beider Ebenen ist der erste große Unterschied zwischen einem Workspace, der so gerade eben läuft, und einem, der ernsthaft Leistung bringt. Das Prinzip stammt aus dem Software Engineering – und es ist überraschend intuitiv: Das Back End ist, wo du Informationen organisierst. Das Front End ist, wo du damit arbeitest.

Wer direkt aus einer zentralen Datenbank heraus arbeitet, hat zwei Probleme:

• Du siehst immer nur ein Objekt. Du kannst deine Deals nicht mit zusätzlichem Kontext daneben anzeigen – du hast nur die Tabelle.
• Es skaliert nicht. Du landest schnell bei einem Dutzend Ansichten, die auf eine einzige Datenbank gestapelt sind – für verschiedene Personen und Situationen. Unübersichtlich, verwirrend – und der Hauptgrund, warum Teams das Gefühl haben, Notion „skaliert nicht”.

Stattdessen sollte dein Team von Dashboards aus arbeiten, die die relevanten Daten in einen UI-freundlichen Kontext ziehen. Eine „Meine Aufgaben”-Seite aus verlinkten Ansichten. Eine Team-Startseite, die aktuelle Deals und laufende Projekte nebeneinander zeigt. Plötzlich fühlt sich Notion wie eine richtige App an – kein Tabellenkalkulationstool mehr.

Das ist auch der einzige Weg, so etwas wie eine „Was liegt bei mir an?”-Seite zu bauen – ein zentraler Ort, an dem jede Person in deiner Organisation alle ihr zugewiesenen Aufgaben, Deals und Projekte auf einen Blick sieht. Kein Durchsuchen eines Dutzend verschiedener Stellen mehr.

Pro-Tipp: Wenn Teammitglieder eine zentrale Datenbank öffnen, um ihre Arbeit zu erledigen, ist das dein Signal zum Dashboard-Bau. Datenbanken organisieren Daten – Dashboards sind, wo Arbeit passiert.

Was ist der Unterschied zwischen Record- und Hub-Dashboards?

Ein Record-Dashboard hängt an einem einzelnen Datenbankeintrag – jedes Projekt, jeder Deal, jeder Kunde bekommt automatisch dasselbe Layout. Ein Hub-Dashboard ist unabhängig von einem bestimmten Eintrag und um eine Funktion herum gebaut: eine Team-Startseite, eine „Was liegt bei mir an?”-Ansicht, ein Sales-Pipeline-Überblick.

Der Unterschied liegt im Aufbau:

• Record-Dashboards entstehen automatisch. Erstell ein drittes Projekt, klick rein – sein Dashboard ist bereits da und zeigt verwandte Aufgaben, Meetings und Dokumente. Einmal bauen, unbegrenzt skalieren.
• Hub-Dashboards sind zweckgebaut. Du designst deine Startseite einmal. Du hast eine „Was liegt bei mir an?”-Seite, eine Seite pro Team. Sie existieren, um etwas Konkretes zu lösen.

Als Faustregel: So gut wie jede Datenbank, die aus anderen Quellen zieht, sollte ein Record-Dashboard haben. Hub-Dashboards entstehen, wenn ein spezifisches Bedürfnis auftaucht – zum Beispiel, dem Sales-Team einen zentralen Ort für ihre Pipeline zu geben.

Wie baust du eine konsistente visuelle Designsprache?

Eine konsistente visuelle Designsprache bedeutet: Dieselben Muster wiederholen sich im gesamten Workspace, sodass auch gelegentliche Nutzende sofort wissen, was sie sehen. Du kannst die beeindruckendsten Dashboards bauen – ohne Konsistenz werden sie jeden verwirren, der nicht täglich darin arbeitet. Drei kleine Gewohnheiten, die sich massiv auszahlen:

1. Ein Icon pro Konzept wählen

Wähle ein Haupticon pro Datenbank und bleibe innerhalb einer Icon-Familie – wenn du die Minimal-Icons nutzt, bleib dabei. Dann geh noch weiter:

• Lass Properties nie mit ihren Standard-Icons. Wähle ein eigenes Icon pro Property und nutze überall dasselbe – wenn „Owner” ein Kreis bei Deals ist, ist er auch ein Kreis bei Aufgaben.
• Relations bekommen immer das Haupticon der Datenbank, auf die sie zeigen. Wenn Unternehmen durch eine Fabrik repräsentiert werden, zeigt jede Relation zu Unternehmen die Fabrik.
• Wende Entry-Icons über ein Standard-Template an, damit jeder neue Eintrag sein Icon automatisch mitbekommt. Für bestehende Einträge: alle auswählen, Rechtsklick, Icon bearbeiten.

Der Mehrwert: Wenn du ein Unternehmen auf einer beliebigen Seite @-erwähnst, reist das Icon mit – jeder weiß sofort, welche Art von Objekt gemeint ist, auch ohne Kontext.

2. Dieselbe Property-Reihenfolge überall

Wenn deine Aufgaben Status, Name, Verantwortliche Person und Fälligkeitsdatum zeigen – zeige sie in dieser Reihenfolge in jeder Ansicht, in jedem Dashboard. Du musst nicht immer dieselbe Anzahl an Properties haben (eine „Erledigt”-Ansicht könnte das Fälligkeitsdatum gegen ein Abschlussdatum tauschen), aber die sichtbaren sollten einem erkennbaren Muster folgen.

3. Einen Dashboard-Archetyp wählen und dabei bleiben

Nutze zumindest beim Ausrollen deines Systems einen der drei Layout-Archetypen (weiter unten beschrieben) für alle Dashboards. Dasselbe Prinzip befolgen App-Designer: Wenn sich Interfaces im gesamten System vertraut anfühlen, orientieren sich Nutzende sofort.

Was gehört auf ein Dashboard? Das NAVI Framework

Jedes Notion Dashboard besteht aus vier Komponenten: Navigation, Actions, Views und Instructions. NAVI ist deine mentale Checkliste – du brauchst nicht immer alle vier, aber du solltest bewusst über jede nachdenken.

• Navigation – Seiten existieren nicht im Vakuum. Frag dich: Wenn ich auf diesem Dashboard bin, wohin würde ich logisch als Nächstes springen? Füge mindestens einen Button zurück zur Hauptseite hinzu – und stelle ihn so ein, dass er als vollständige Seite öffnet, nicht als Pop-up.
• Actions – Was sollte hier einfach zu erledigen sein? Quick-Capture-Buttons zum Hinzufügen einer Aufgabe, zum Erstellen eines Eintrags und so weiter.
• Views – Das Herzstück der meisten Dashboards: verlinkte Datenbankansichten, die aus deinem Back End ziehen. Das nimmt den größten Teil des Bildschirms ein.
• Instructions – Tipps und Erklärungen direkt auf der Seite. Eine der unterschätzten Stärken von Notion, besonders wenn du für Kolleginnen und Kollegen baust, die nicht täglich mit dem Setup interagieren.

Wie entscheidest du, was ein Dashboard zeigen soll?

Definiere den Job des Dashboards, bevor du mit dem Design anfängst. Angelehnt an das Jobs-to-be-done-Framework sollte jedes Dashboard diesen Satz vervollständigen können:

Wenn [Situation], öffne ich dieses Dashboard, um [Information] zu sehen, damit ich [Ergebnis] erreichen kann.

Ein paar Beispiele:

• „Wenn ich morgens mit der Arbeit anfange, öffne ich ‘Was liegt bei mir an?’, um alles zu sehen, wofür ich verantwortlich bin, damit ich entscheiden kann, was ich als Nächstes angehe.” – Orientierung und Priorisierung.
• „Wenn das Sales-Team sich zum wöchentlichen All-Hands trifft, öffnen wir dieses Dashboard, um Pipeline-Metriken zu reviewen, damit wir die nächsten Schritte festlegen können.” – Meeting-getrieben.

Bei Record-Dashboards ist der Job meistens offensichtlich: Zeige alles, was mit diesem Eintrag zusammenhängt, damit du zu verwandten Informationen springen kannst. Bei Hub-Dashboards ist die Welt offen – was sie schwieriger zu designen macht. Fang mit den einfachen Gewinnen an: individuelle Übersichtsseiten, Team-Dashboards, dann Meeting-getriebene Dashboards.

Du kannst auch KI dabei nutzen. Füge diesen Prompt in Notion AI ein und lass dich interviewen:

You are an experienced Notion consultant helping me design a dashboard.

Interview me one question at a time. Ask about:
1. Who this dashboard is for (individual, team, or role)
2. The specific situation in which they'll open it
3. What they need to see in that moment
4. What they need to be able to do from there
5. What decision or outcome the dashboard should enable
6. Where they'd want to navigate to next

After the interview, summarise the dashboard's job in this format:
"When [situation], I open this dashboard to see [information],
so I can [outcome]."

Then propose the dashboard contents using the NAVI framework:
- Navigation: links or buttons to related pages
- Actions: quick-capture buttons or shortcuts
- Views: the specific database views, including filters and sorts
- Instructions: any on-page guidance for users

Keep the dashboard as lean as possible — challenge me if I try to
add elements that don't serve the core job.

Pro-Tipp: Baue lieber mehr kleine Dashboards als wenige große. Mega-Dashboards zwingen Leute, durch Lärm zu scrollen, um das zu finden, was sie brauchen – was genau den Punkt verfehlt, warum du überhaupt von zentralen Datenbanken weggehst.

Was sind die drei Notion Dashboard-Archetypen?

Es gibt drei Dashboard-Layouts: den Vertical Stack, den Horizontal Stack und die Dashboard-Ansicht. Sie liegen auf einer Skala – der Vertical Stack bietet die höchste Informationsdichte, die Dashboard-Ansicht den höchsten visuellen Schliff.

Ein Hinweis vorab: Ein gut durchdachtes Dashboard mit einem klaren Job schlägt immer eines, das toll aussieht, aber keinen hat. Viele schöne Screenshots online sind genau das – schön, aber nicht funktional. Erst den Job klären, dann das Layout wählen:

Archetyp	Gebaut mit	Informationsdichte	Visueller Schliff	Am besten für	Haupteinschränkung
Vertical Stack	Callouts + Toggle-Überschriften + verlinkte Ansichten	Hoch – mehrere Bereiche gleichzeitig offen	Mittel	Informationsdichte persönliche oder Team-Übersichten	Weniger poliertes Aussehen; Seiten werden lang
Horizontal Stack	Tab-Blöcke + verlinkte Ansichten	Mittel – immer nur ein Tab sichtbar	Hoch	Saubere Übersichten mit klar getrennten Bereichen	Immer nur der Inhalt eines Tabs sichtbar
Dashboard-Ansicht	Notions Dashboard-Ansicht mit Widgets	Niedriger – feste Widget-Höhen	Am höchsten – App-artiges Grid-Design	Polierte Überblicksseiten, Charts und Metriken	Eine Ansicht pro Widget; max. 4 Widgets pro Zeile, 12 insgesamt

Wie baust du einen Vertical Stack Dashboard?

Der Vertical Stack kombiniert drei Komponenten: Callouts, Toggle-Überschriften und verlinkte Datenbankansichten.

1. Tippe /callout, klicke auf das Icon, um es zu entfernen, und stelle die Farbe über die sechs Punkte auf Standardhintergrund. Du bekommst eine saubere umrahmte Box – wie Container im Web-Design.
2. Füge innerhalb des Callouts eine Toggle Überschrift 2 ein und benenne sie nach dem Bereich (z. B. „Aufgaben”).
3. Tippe innerhalb des Toggles /verlinkte Datenbankansicht und wähle die Datenbank aus deinem Back End.

Dann geh den View-Setup-Prozess durch – vier Entscheidungen für jede Ansicht, die du je erstellst:

1. Property-Sichtbarkeit – Welche Properties werden angezeigt, und in welcher Reihenfolge? Überall dieselbe Reihenfolge beibehalten.
2. Name und Icon – Benenne die Ansicht um (z. B. „Offen”) und gib ihr ein konsistentes Icon, wie eine leere Checkbox für offene Aufgaben.
3. Filter – z. B. Verantwortliche enthält Ich, und Status ist nicht abgeschlossen. „Ich” ist dynamisch: Einmal bauen, und der Filter greift für jeden, der die Seite aufruft. Eine Person fest einzutragen macht nur Sinn für Team- oder rollenspezifische Dashboards.
4. Sortierung – z. B. frühestes Fälligkeitsdatum zuerst.

Optional: Gruppierungen oder bedingte Farben ergänzen – zum Beispiel Hochprioritäts-Zeilen hervorheben – aber nur, wenn es dem Job des Dashboards dient. Von dort aus kannst du den Callout für Projekte, Meetings, Dokumente und alles andere duplizieren, was auf die Seite gehört, und dann Navigation und Action-Buttons oben ergänzen.

Pro-Tipp: Halte Tabellen-Ansichten in einer einzigen Spalte – sie brauchen die Breite, besonders auf einem Standard-Laptop-Bildschirm. Minimalistische Layouts wie Listen funktionieren gut nebeneinander in zwei Spalten. Und sobald eine Seite Datenbankansichten enthält: Vollbreite über das Drei-Punkte-Menü aktivieren.

Wie baust du einen Horizontal Stack Dashboard mit Tabs?

Tabs sind eine neuere Notion-Funktion, die diesen Archetyp erst möglich macht. Tippe /tabs und Notion erstellt einen Callout-artigen Container mit horizontalen Tabs – jeder Tab verhält sich wie eine eigene Mini-Seite, mit allen verfügbaren Block-Typen darin.

Benenne deine Tabs (Aufgaben, Projekte, Meetings), und füge dann die relevanten verlinkten Datenbankansichten in jeden ein. Das Ergebnis ist ein sehr sauberes Erscheinungsbild: viele Informationen auf der Seite, aber immer nur ein Ausschnitt sichtbar.

Das ist auch der Trade-off gegenüber dem Vertical Stack: Toggles lassen dich Aufgaben und Meetings gleichzeitig offen haben; Tabs zeigen immer nur einen Bereich. Saubereres Aussehen, weniger paralleler Kontext – wähle basierend auf dem Job.

Pro-Tipp: Richte „Master-Ansichten” in deinen Back-End-Datenbanken ein – eine Standard-Tabelle und ein Standard-Board mit deinen üblichen Properties, Filtern und Sortierungen. Jede verlinkte Ansicht, die du überall im Workspace erstellst, kann mit einem einzigen Klick von einer dieser Ansichten starten – du bist sofort zu 50–80 % fertig und behältst deine visuelle Designsprache konsistent, ohne jedes Mal von vorne anzufangen.

Wie baust du eine Dashboard-Ansicht?

Die Dashboard-Ansicht ist Notions vorgefertigtes Grid-Layout – verwirrenderweise so benannt, da ja alle diese Seiten Dashboards sind, aber es ist die App-artigste Option der drei. Tippe /dashboard (oder füge einer Datenbank eine Dashboard-Ansicht hinzu) und du kannst einzelne Datenbankansichten in ein Widget-Grid einsetzen.

Nutze den Bearbeiten-Modus, um Widgets hinzuzufügen, neu anzuordnen und ihre Höhe und Breite anzupassen; nutze den Ansicht-Modus für die tägliche Arbeit. Ein paar Dinge, die sie auszeichnen:

• Das polierteste Aussehen – dezente Hintergrundschattierung, schwebende Badges und konsistente Container, die du mit normalen Blöcken nicht nachbauen kannst.
• Feste Widget-Höhen – längere Listen scrollen innerhalb ihres Widgets, statt die Seite zu verlängern.
• Kapazitätsgrenzen – bis zu 4 Widgets pro Zeile und 12 Widgets insgesamt.

Der Haken: Jedes Widget hält genau eine Datenbankansicht. Es gibt kein Stapeln von „Offene Aufgaben / Erledigte Aufgaben / Heute fällig” innerhalb eines einzigen Widgets – jede Art, deine Daten zu schneiden, braucht ihren eigenen Platz auf der Seite. Wenn du Informationen auf viele Weisen aufschlüsseln musst, landest du schnell im Mega-Dashboard-Bereich. Aber wenn deine Anforderungen einfach sind – hier ist, woran ich arbeite, hier ist, was erledigt ist – ist das eine unglaublich saubere Art, es darzustellen.

💼 Brauchst du die Unterstützung zertifizierter Notion Berater? Mein Team und ich helfen gern!

Solltest du Templates oder Layouts für Record-Dashboards nutzen?

Record-Dashboards können auf zwei Arten gebaut werden: als Datenbank-Templates oder als Datenbank-Layouts. Templates steuern den Seiteninhalt und werden beim Erstellen angewendet; Layouts steuern, wie jede Seite in der Datenbank aussieht, und werden sofort auf alle Einträge angewendet. Die meisten ernsthaften Setups nutzen beides.

Record-Dashboards mit Templates bauen

Ein Template definiert Seiteninhalt, der auf neue Einträge übertragen wird. Baue dein Dashboard im Template – Tabs, Callouts, Ansichten, was immer du brauchst – und stelle es dann über die drei Punkte neben dem Template-Namen als Standard ein. Jeder neue Eintrag kommt nun mit seinem fertigen Dashboard an.

Der entscheidende Trick: Wenn du eine verlinkte Ansicht innerhalb eines Templates hinzufügst, setze einen erweiterten Filter wie Fund enthält [Template-Name] – wähle das Template selbst aus, das ganz oben in der Liste steht. Klicke auf Für alle speichern, und Notion aktualisiert diesen Filter automatisch für jeden neuen Eintrag. Das Dashboard jedes Eintrags filtert sich selbst auf seine eigenen verwandten Elemente – ohne manuellen Aufwand.

Der Nachteil: Templates werden nur beim Erstellen angewendet. Ändere das Template später, und bestehende Einträge behalten die alte Version. Du kannst das Template auf einer Seite erneut anwenden – aber jeder direkt auf dieser Seite geschriebene Text geht dabei verloren. Also mit Bedacht vorgehen.

Record-Dashboards mit Layouts bauen

Ein Layout steuert das Aussehen jeder Seite in einer Datenbank – und Änderungen werden sofort auf alle Einträge angewendet, auch bestehende. Hover über einen Eintrag und klicke auf Layout anpassen, um es zu gestalten.

Zwei schnelle Wins für so gut wie jede Datenbank:

• Verschiebe die Property-Gruppe in das Seitenpanel, damit eine lange Property-Liste nicht den Bildschirm auffrisst.
• Pinne die Properties, die du immer sehen möchtest – Notion unterstützt jetzt bis zu 15 angepinnte Properties, mehr als die früheren vier.

Für Dashboards speziell: Wechsle die Layout-Struktur von Einfach zu Tab. Jeder Layout-Tab hält genau eine Datenbankansicht einer verwandten Datenbank – keine Texte, keine Buttons, nur die Ansicht. Das deckt das V in NAVI hervorragend ab, aber Navigation, Actions und Instructions müssen weiterhin in einem Template leben, wenn du sie haben möchtest.

Pro-Tipp: Um mehrere Ansichten innerhalb eines einzelnen Layout-Tabs zu stapeln, stelle den Ansichtstyp dieses Tabs auf Dashboard. So können „Meine offenen Aufgaben”, „Alle Aufgaben” und „Abgeschlossen” in einem Tab leben, statt die Seiten-Header mit drei separaten Pills zu überhäufen.

Wie schützt du deine Dashboards vor unbeabsichtigten Änderungen?

Eine Seite zu sperren reicht nicht. Jede Person mit Bearbeitungszugriff kann sie entsperren – und eine gesperrte Seite verhindert auch direkte Interaktionen wie das Abhaken von Aufgaben oder das Verschieben von Karten. Der richtige Schutz ist ein dreistufiges Berechtigungs-Setup:

1. Die Dashboard-Seite einschränken. In den Teilen-Einstellungen alle außer deiner Admin-Gruppe auf Kann kommentieren (oder Kann anzeigen) senken. „Kann kommentieren” ist praktisch – Leute können noch Verbesserungen vorschlagen.
2. Jede verlinkte Datenbankansicht als vollständige Seite öffnen. Klicke auf die sechs Punkte der Ansicht und wähle Als vollständige Seite öffnen. Das ist wichtig: Die nächste Einstellung greift auf der verlinkten Ansicht in deinem Dashboard, nicht auf der ursprünglichen Datenbank.
3. Die Team-Gruppe auf „Kann Inhalt bearbeiten” in den Teilen-Einstellungen dieser verlinkten Ansicht anheben.

Das Ergebnis: Dein Team kann Aufgaben abhaken, Karten über ein Kanban-Board ziehen und Properties aktualisieren – aber niemand kann Blöcke verschieben, Ansichtskonfigurationen ändern, Properties hinzufügen oder die Seite umstrukturieren. Das Dashboard verhält sich wie eine richtige App: interaktive Daten, festes Interface.

Du musst die Schritte 2–3 einmal pro verlinkter Datenbank auf der Seite wiederholen (Ansichten aus derselben Quelle sind zusammen abgedeckt). Einmal Aufwand – und niemand kann danach deine sorgfältig gebauten Dashboards verändern.

Wie verändert KI das Notion Dashboard-Design?

KI verkleinert den „Actions”-Teil von NAVI dramatisch. Wenn du einfach Notion AI sagen kannst „Füge eine Aufgabe für morgen hinzu”, brauchst du keine Capture-Buttons mehr, die die UI belasten – manuelle Aufgabeneingabe wird ehrlich gesagt schnell zur Vergangenheit.

Das verschiebt das Dashboard-Design hin zu saubereren, schlankeren Seiten: die wichtigsten Informationen anzeigen, und KI das Aufschlüsseln und Filtern übernehmen lassen. „Welche davon sind heute fällig?” ist eine Frage entfernt – du brauchst dafür keine eigene gefilterte Ansicht mehr.

Das macht auch die polierte, niedrigere Dashboard-Ansicht attraktiver als noch vor einem Jahr: weniger UI zu pflegen, mit KI, die die Flexibilitätslücke schließt.

Und natürlich kann KI Dashboards für dich bauen. Sobald du die Bausteine aus diesem Guide kennst, kannst du sie in Anweisungen verwandeln – „nutze Tabs, behalte Properties in dieser Reihenfolge, filtere nach Ich” – und KI die Seite zusammensetzen lassen. Den manuellen Weg zu kennen ist genau das, was den KI-Weg funktionieren lässt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Dashboard und einer Datenbank in Notion?

Eine Datenbank speichert und organisiert deine Daten – sie ist das Back End. Ein Dashboard ist eine normale Notion-Seite, die verlinkte Ansichten aus einer oder mehreren Datenbanken in einen Kontext zieht, in dem Leute tatsächlich arbeiten – es ist das Front End. Dein Team sollte von Dashboards aus arbeiten, nicht von zentralen Datenbanken.

Kann ein Dashboard für jede Person im Team funktionieren?

Ja – nutze den dynamischen Ich-Filter für deine Datenbankansichten. Er filtert automatisch auf die Person, die die Seite aufruft, sodass ein einziges „Was liegt bei mir an?”-Dashboard jedem Teammitglied genau ihre eigenen Aufgaben, Projekte und Deals zeigt. Einmal bauen, das gesamte Team kann es nutzen.

Solltest du Notion Dashboards sperren?

Sperren verhindert nur versehentliche Änderungen – jede Person mit Bearbeitungszugriff kann die Seite entsperren, und Sperren blockiert auch schnelle Interaktionen wie das Abhaken von Aufgaben. Stelle stattdessen die Dashboard-Seite für dein Team auf „Kann kommentieren” und hebe jede verlinkte Datenbankansicht auf „Kann Inhalt bearbeiten” an. So bleibt das Layout fest, während die Daten vollständig interaktiv bleiben.

Wie viele Widgets passen in eine Notion Dashboard-Ansicht?

Eine Dashboard-Ansicht unterstützt bis zu 4 Widgets pro Zeile und 12 Widgets insgesamt. Jedes Widget zeigt genau eine Datenbankansicht, und du kannst Widget-Höhen und -Breiten im Bearbeitungs-Modus anpassen.

Solltest du ein Template oder ein Layout für Record-Dashboards nutzen?

Nutze Layouts für Struktur, die sofort auf alle Einträge aktualisiert werden soll – angepinnte Properties und Tabs mit verwandten Datenbankansichten. Nutze Templates für eigentlichen Seiteninhalt: Text, Instructions, Buttons und frei angeordnete Ansichten. Templates werden nur beim Erstellen angewendet, daher sind Layout-basierte Elemente langfristig einfacher zu pflegen.

---

💡 Lust auf mehr Tipps? Tritt 39.000 Notion-Fans in unserem zweiwöchentlichen Newsletter bei und erhalte Zugang zu 41+ kostenlosen Ressourcen