Notion Property Access gibt dir präzise Kontrolle darüber, wer jede Eigenschaft in einer Datenbank sehen und bearbeiten darf. Das Feature ergänzt Notions Berechtigungssystem um eine wichtige Ebene: Du kannst sensible Werte schützen, kritische Felder sperren und einschränken, was Personen oder Agents ändern dürfen – ohne deine Daten auf mehrere Datenbanken aufzuteilen.
Zuletzt aktualisiert: 27. September 2026
Was ist Notion Property Access?
Notion Property Access lässt dich steuern, wer eine Datenbankeigenschaft sehen und wer ihre Werte ändern darf. Notion nennt das Feature offiziell Property access, auch wenn du es vielleicht auch als eigenschafts- oder spaltenbasierte Berechtigungen kennst.
Bisher waren Datenbankberechtigungen eher grob. Wer eine Seite öffnen konnte, konnte in der Regel auch alle zugehörigen Eigenschaften sehen. Die Datenbankberechtigung legte dann fest, ob jemand diese Werte bearbeiten oder die Datenbankstruktur ändern darf.
Property Access fügt eine weitere Ebene hinzu. Eine Person kann die Seite weiterhin öffnen, sieht aber nur die Eigenschaften, die für sie relevant sind.
Zum Beispiel kannst du:
- Allen erlauben, den Status einer Aufgabe zu sehen, aber nur dem Verantwortlichen erlauben, ihn zu ändern
- Eine interne Notizen-Eigenschaft vor Personen außerhalb deines Teams verbergen
- Einer Abteilung erlauben, ein Budget einzusehen, ohne es bearbeiten zu können
- Einem Agent erlauben, ein Feld zu aktualisieren, ohne den Rest der Datenbank anzufassen
- Sensible Eigenschaften aus öffentlich veröffentlichten Seiten heraushalten
Das Feature ist in Notions Business- und Enterprise-Plänen verfügbar. Du benötigst Full access auf eine Datenbank, um Regeln zu erstellen oder zu ändern. Die Konfiguration ist auf Web und Desktop möglich, nicht auf Mobilgeräten.
Wie richtest du Property Access in Notion ein?
Du konfigurierst Property Access in der Original-Datenbank in einer Tabellenansicht. Jede Regel kombiniert eine Standard-Zugriffsebene mit Ausnahmen für Personen, die mehr oder weniger Zugriff benötigen.
- Öffne die Original-Datenbank im Web oder auf dem Desktop – nicht in einer verknüpften Ansicht.
- Öffne das Menü der Eigenschaft, die du kontrollieren möchtest.
- Wähle Property access.
- Wähle den Standard-Zugriff für alle, die die Datenbank öffnen können.
- Füge Ausnahmen für bestimmte Personen, Gruppen, Personen-Eigenschaften oder Agents hinzu.
- Wähle die Zugriffsebene für jede Ausnahme.
- Wähle Preview und wähle einen Nutzer, um das Ergebnis zu testen.
- Speichere die Regel.
Du kannst dieselbe Regel auf mehrere Eigenschaften gleichzeitig anwenden. Nach dem Speichern zeigt ein kleines Schloss-Symbol, dass eine Eigenschaft eine benutzerdefinierte Zugriffsregel hat.
Bestehende Regeln findest du auch über die Eigenschaftseinstellungen der Datenbank. Wichtig: Diese Einstellungen befinden sich auf Eigenschaftsebene der Datenbank – nicht im allgemeinen Teilen-Menü.
Pro-Tipp: Teste die Regel immer als jemanden ohne Full access. Full-Access-Nutzer können nicht eingeschränkt werden – als Admin zu testen gibt dir ein falsches Bild.
Welche Zugriffsebenen gibt es bei Property Access?
Notion bietet sechs Zugriffsebenen – von der geerbten Datenbankberechtigung bis zum vollständigen Verbergen der Eigenschaft.
- Inherit from database: Die Datenbankberechtigung der Person bestimmt, was sie tun darf.
- Can edit property & values: Die Person kann sowohl die Eigenschaft selbst als auch ihre Werte ändern.
- Can edit values only: Die Person kann Werte aktualisieren, ohne die Eigenschaft selbst zu verändern.
- Can view property & values: Die Person kann die Eigenschaft und ihre Werte sehen, aber nicht bearbeiten.
- Can view property only: Die Person sieht, dass die Eigenschaft existiert, aber ihre Werte bleiben verborgen.
- No access: Die Eigenschaft und ihre Werte sind vollständig ausgeblendet.
In den meisten realen Setups wirst du Property Access nutzen, um das Standardverhalten einzuschränken. Du machst eine bearbeitbare Eigenschaft schreibgeschützt oder verbirgst sie vor bestimmten Personen.
Es gibt auch Fälle, in denen du mehr Zugriff gewähren kannst. Zum Beispiel könnte ein Team mit Can edit content in einer Datenbank die Berechtigung erhalten, Werte in einer bestimmten Eigenschaft zu verwalten, während die restliche Datenbankstruktur geschützt bleibt.
Wie funktionieren Datenbank-, Seiten- und Eigenschaftsberechtigungen zusammen?
Datenbank- und Seitenberechtigungen entscheiden, ob jemand eine Seite öffnen darf. Property Access entscheidet, was diese Person nach dem Öffnen sehen und ändern darf.
Stell dir Notions Berechtigungen als einen Wasserfall vor:
- Datenbankzugriff: Hat die Person Zugriff auf die Datenbank und ihre Seiten?
- Seitenzugriff: Wenn die Datenbank eingeschränkt ist – gibt es eine Regel, die dieser Person Zugriff auf diese spezifische Seite gibt?
- Property Access: Sobald die Seite geöffnet ist – welche Eigenschaften kann die Person sehen oder bearbeiten?
Property Access gewährt niemals Zugriff auf eine Seite, auf die jemand normalerweise keinen Zugriff hätte. Wenn die ersten beiden Ebenen „Nein” sagen, spielen die Eigenschaftsregeln keine Rolle.
| Berechtigungsebene | Was sie steuert | Typischer Anwendungsfall |
|---|---|---|
| Datenbankzugriff | Ob jemand die Datenbank und ihre Seiten aufrufen darf | Dem Team Zugriff auf die gemeinsame Aufgaben-Datenbank geben |
| Seitenzugriff | Welche einzelnen Datenbankseiten jemand öffnen darf | Einem Kunden nur die für ihn relevanten Projekte zeigen |
| Property Access | Welche Eigenschaften jemand sehen oder ändern darf | Interne Notizen verstecken oder ein Genehmigungsfeld sperren |
Dieser Unterschied ist wichtig: Eine Eigenschaft zu verstecken ersetzt nicht das Einschränken des Seitenzugriffs. Wenn jemand eine Seite gar nicht sehen soll, löse das zuerst auf Datenbank- oder Seitenebene.
Wie kannst du nur Aufgaben-Verantwortlichen erlauben, einen Status zu ändern?
Setze die Status-Eigenschaft standardmäßig auf „Nur anzeigen” und gib der in der Verantwortlicher-Eigenschaft genannten Person das Recht, ihre Werte zu bearbeiten.
Die Regel sähe so aus:
- Eigenschaft: Status
- Standard-Zugriff: Can view property & values
- Ausnahme: Verantwortlicher
- Ausnahme-Zugriff: Can edit values only
Alle, die die Aufgabe öffnen können, sehen, ob sie offen oder abgeschlossen ist. Nur der zugewiesene Verantwortliche kann diesen Wert ändern.
Ein wichtiges Schlupfloch: Können Personen die Verantwortlicher-Eigenschaft selbst bearbeiten? Wenn sie sich selbst zuweisen können, können sie sich auch in die Status-Regel eintragen.
Unter Umständen musst du daher beide Eigenschaften sperren: Schütze das Aktionsfeld, aber auch jedes Feld, das bestimmt, wer Zugriff auf dieses Aktionsfeld erhält.
Wie kannst du interne Eigenschaften auf öffentlichen Seiten verbergen?
Setze den Standard-Zugriff der Eigenschaft auf No access und füge dein internes Team als Ausnahme hinzu. Öffentliche Besucher sehen die Eigenschaft nicht, dein Team kann weiterhin damit arbeiten.
Stell dir zum Beispiel eine Datenbank mit offenen Stellenanzeigen vor, die auf der Website veröffentlicht wird. Kandidaten sollen die Rolle, den Standort und die Beschreibung sehen – aber keine internen Notizen zum Hiring-Prozess.
Konfiguriere die Hiring Notes-Eigenschaft so:
- Standard-Zugriff: No access
- Ausnahme: Deine interne Team-Gruppe
- Ausnahme-Zugriff: Can edit values only
Das folgt dem sichersten allgemeinen Berechtigungsmuster: Beginne mit dem niedrigsten notwendigen Zugriff und aktiviere vertrauenswürdige Personen dann explizit.
Notion bietet keinen speziellen Schalter „Nur auf öffentlichen Seiten ausblenden”. Du erreichst das Ergebnis über den Standard-Zugriff und interne Ausnahmen.
Wann solltest du eine Eigenschaft anzeigen, aber ihre Werte verbergen?
Nutze Can view property only, wenn Personen wissen sollen, dass ein Feld existiert, aber seinen Inhalt nicht sehen dürfen. In den meisten alltäglichen Setups ist das vollständige Ausblenden irrelevanter Eigenschaften die sauberere Lösung.
„No access” überall auf einer Seite zu sehen erzeugt Rauschen und wirft Fragen auf. Wenn ein Feld für jemanden keine Bedeutung hat, ist No access meistens die bessere Wahl.
Es gibt aber Ausnahmen. Du möchtest vielleicht, dass jemand weiß, dass:
- Ein Genehmigungsfeld existiert, aber nur Manager die Entscheidung sehen dürfen
- Eine Audit-Eigenschaft existiert, deren Werte jedoch vertraulich sind
- Ein kontrollierter Prozess stattfindet, ohne die zugrunde liegenden Informationen offenzulegen
Eine versteckte Personen-Eigenschaft kann auch den Zugriff auf eine andere Eigenschaft steuern. Stell es dir wie eine Gästeliste vor: Personen wissen, dass die Liste existiert, und können prüfen, ob ihr Name ihnen Zugang gewährt – ohne alle anderen auf der Liste zu sehen.
Wie funktioniert Property Access mit Formeln und Automationen?
Buttons, Automationen, Formeln und Rollups respektieren weiterhin die Eigenschaftsberechtigungen. Ein Workflow kann fehlschlagen oder verwirrende Ergebnisse liefern, wenn die ausführende Person keinen Zugriff auf eine der Eingabe-Eigenschaften hat.
Bei Tests haben Formeln, die auf eingeschränkten Eigenschaften basieren, den fehlenden Zugriff nicht immer klar kommuniziert. Je nach Formel und Einschränkung kann ein Ergebnis leer erscheinen, als Null ausgegeben werden oder sich anders als erwartet verhalten.
Das erzeugt zwei Risiken:
- Ein Nutzer könnte einen fehlenden Wert als echte Daten interpretieren.
- Eine Automation könnte nicht abgeschlossen werden, weil sie eine erforderliche Eigenschaft nicht lesen oder ändern kann.
Teste jede abhängige Formel und jeden Workflow als die tatsächliche Zielgruppe – nicht als Admin. Wenn ein berechnetes Ergebnis sensible Informationen aus einer versteckten Eingabe preisgibt, schränke auch die Ausgabe-Eigenschaft ein.
Notions offizieller Troubleshooting-Rat folgt derselben Logik: Wenn ein Workflow aufhört zu funktionieren, teste ihn als jemanden, der die Eigenschaft sehen kann. Wenn er dann funktioniert, fehlt dem ursprünglichen Nutzer wahrscheinlich der Zugriff auf ein erforderliches Feld.
Wie funktioniert Property Access für Notion AI und Agents?
Agents können eigene Eigenschaftsberechtigungen erhalten, während Notion AI in der Regel die Berechtigungen der nutzenden Person erbt. Ein Agent kann keine Eigenschaft verwenden, auf die er keinen Zugriff hat.
Das schafft eine nützliche Sicherheitsgrenze. Du kannst einem Agent oder einer Automation Zugriff auf die Datenbank geben und gleichzeitig einschränken, welche Felder er lesen oder ändern darf.
Ein Dokumentations-Agent könnte zum Beispiel:
- Titel, Beschreibung und Projekt einer Aufgabe lesen
- Eine Dokumentations-Status-Eigenschaft aktualisieren
- Den Haupt-Status der Aufgabe ansehen, aber nicht bearbeiten
- Keinen Zugriff auf vertrauliche Budget- oder Kunden-Notiz-Eigenschaften haben
Das ist eine enorme Verbesserung für agentische Workflows. Bisher machte der breite Datenbankzugriff einer Integration es schwieriger, Grenzen auf Feldebene durchzusetzen. Property Access lässt dich das Prinzip der minimalen Berechtigung anwenden: Gib dem Agent nur, was er für seine Aufgabe braucht.
Beachte: Ein eingeschränkter Agent meldet möglicherweise, dass eine Eigenschaft nicht existiert. Aus seiner Perspektive kann das wahr sein – nicht zugängliche Eigenschaften stehen ihm nicht zur Verfügung.
Was sind die wichtigsten Einschränkungen und Stolperfallen?
Property Access ist mächtig, aber kein Ersatz für ein gut durchdachtes Berechtigungsmodell. Einige Regeln können überraschende Ergebnisse liefern, wenn du sie übersiehst.
Full-Access-Nutzer können nicht eingeschränkt werden
Wer Full access auf die Datenbank hat, hat immer vollen Zugriff auf alle Eigenschaften. Eine Spaltenregel kann sie nicht herabstufen.
Halte Full access auf eine kleine Admin-Gruppe beschränkt. Gib dem größeren Team wo immer möglich Can edit content oder weniger.
Notion wendet den breitesten passenden Zugriff an
Wenn jemand mehrere Ausnahmen erfüllt, gibt Notion ihm die am wenigsten restriktive Zugriffsebene. Breiteres Sharing anderswo kann daher die von dir erwartete Einschränkung aufheben.
Wenn jemand eine Eigenschaft noch sieht, überprüfe das vollständige Teilen-Menü und jede Ausnahme – nicht nur eine Regel in Isolation.
Eingeschränkte Eigenschaften können Ansichten beschädigen
Eine Ansicht kann sich nicht öffnen, wenn sie nach einer Eigenschaft filtert, sortiert oder gruppiert, die der Nutzer nicht sehen darf. Baue zielgruppenspezifische Ansichten, die nur Eigenschaften nutzen, die dieser Zielgruppe zugänglich sind.
Einige Eigenschaften können nicht eingeschränkt werden
Zu Notions aktuellen Einschränkungen gehören Title, ID, Erstellungs- und Bearbeitungsmetadaten, bestimmte synchronisierte Eigenschaften sowie Unter-Item- oder Eltern-Relation-Eigenschaften. Property Access ist zudem in Wiki-Datenbanken nicht verfügbar.
Große Regelsets können die Performance beeinträchtigen
Datenbanken mit vielen Property-Access-Regeln können langsamer laden, besonders wenn Ansichten nach eingeschränkten Eigenschaften sortieren, filtern oder gruppieren.
Verknüpfte Ansichten können sich anders verhalten
Regeln müssen in der Original-Datenbank konfiguriert werden. In meinen Tests verhielten sich erweiterte Eigenschaftsberechtigungen in einem Szenario zwischen der Quelldatenbank und einer verknüpften Ansicht unterschiedlich.
Behandle das als Interface-Eigenheit, nicht als Teil deines Zugriffsmodells. Teste sowohl die Original-Datenbank als auch die verknüpften Ansichten, die dein Team tatsächlich nutzt.
Was ist das beste Berechtigungs-Setup?
Nutze Gruppen, minimiere Full access und beginne jede sensible Regel mit dem niedrigsten sinnvollen Standard. Füge dann explizite Ausnahmen für Personen oder Agents hinzu, die mehr benötigen.
Eine solide Basis sieht so aus:
- Admins: Full access auf Datenbanken
- Team: Can edit content, ohne Berechtigung, das Schema zu ändern
- Externe Mitarbeitende: Nur Ansichts- oder Seitenzugriff, wo nötig
- Agents und Integrationen: Zugriff beschränkt auf die für ihren Workflow erforderlichen Eigenschaften
- Sensible Eigenschaften: Standardmäßig No access oder nur ansehen, mit benannten Ausnahmen
Verwalte Personen über Gruppen statt Dutzende von Einzelpersonen zu jeder Regel hinzuzufügen. Gruppen sind einfacher zu prüfen und bleiben konsistent, wenn sich dein Team verändert.
Am wichtigsten: Entwirf Berechtigungen als vollständiges Modell. Datenbankzugriff, Seitenzugriff und Property Access sollten sich gegenseitig stärken – nicht als isolierte Patches funktionieren.
📩 Für weitere praktische Notion-Guides: Trag dich in den Newsletter ein und erhalte 41 kostenlose Notion-Ressourcen.
💼 Brauchst du die Unterstützung zertifizierter Notion Berater? Mein Team und ich helfen dir gerne!
Häufig gestellte Fragen
Wie heißt das Feature für spaltenbasierte Berechtigungen in Notion offiziell?
Notion nennt das Feature Property access. „Eigenschaftsbasierte Berechtigungen” und „spaltenbasierte Berechtigungen” sind nützliche beschreibende Begriffe, aber Property access ist die Bezeichnung in Notions Interface und offizieller Dokumentation.
Kann Property Access jemandem Zugriff auf eine Datenbankseite geben?
Nein. Property Access greift erst, nachdem jemand die Seite bereits öffnen kann. Nutze Datenbankfreigabe oder Seitenzugriffsregeln, um zu steuern, auf welche Seiten jemand zugreifen darf.
Kannst du eine Notion-Eigenschaft vor bestimmten Personen verbergen?
Ja. Setze den Standard der Eigenschaft auf No access und füge Ausnahmen für alle hinzu, die sie weiterhin sehen oder bearbeiten sollen. Notions Modell funktioniert am besten, wenn du standardmäßig einschränkst und zugelassene Personen dann explizit wieder aktivierst.
Können Full-Access-Nutzer von einer Eigenschaft ausgeschlossen werden?
Nein. Wer Full access auf die Datenbank hat, hat immer vollen Zugriff auf alle Eigenschaften. Reduziere zuerst ihre Datenbankberechtigung, wenn sie Eigenschaftsregeln unterliegen sollen.
Gelten Notion-Eigenschaftsberechtigungen für AI-Agents?
Ja. Agents können eigene Eigenschaftsberechtigungen haben, und Notion AI erbt in der Regel die Berechtigungen der nutzenden Person. Wenn ein Agent auf eine Eigenschaft keinen Zugriff hat, kann er sie weder lesen noch aktualisieren – und meldet möglicherweise, dass die Eigenschaft nicht existiert.
Die vollständige und aktuelle Funktionsreferenz findest du in Notions offizieller Property-Access-Dokumentation.
