Notion als zentrales System für Automatisierung: warum ich es selten empfehle

Notion als zentrales System für Automatisierung: warum ich es selten empfehle

Vor zwei Jahren saß ich bei einem Kunden im Workshop. Eine Marketing-Agentur, sechzehn Personen, alles in Notion: Kundenakten, Projektpläne, Rechnungsentwürfe, Onboarding-Checklisten. Auf der Wand hing ein selbstgemaltes Schaubild, in der Mitte das Notion-Logo, drumherum Pfeile zu HubSpot, Slack, Stripe, Google Drive, Make. "Notion ist unser Betriebssystem", sagte der Geschäftsführer stolz.

Sechs Wochen später hatten wir alles auf eine andere Architektur umgebaut.

Notion ist ein gutes Werkzeug. Für Dokumente, Wikis, schnelle Tabellen, das interne Handbuch. Aber als zentrale Datenquelle in einer automatisierten Prozesslandschaft ist es selten die richtige Wahl, und dieser Artikel erklärt warum.

Was ein zentrales System leisten muss

Wenn Sie Automatisierung ernst meinen, brauchen Sie eine Datenquelle, der Ihre Workflows vertrauen können. Konkret muss sie drei Dinge können.

Erstens: Echtzeitfähig benachrichtigen, wenn sich etwas ändert. Ein Eintrag entsteht, wird verändert oder gelöscht, Ihre anderen Systeme erfahren davon, ohne dass jemand pollt.

Zweitens: Sauber abfragen lassen. Wenn Sie "alle Aufträge ohne Rechnung der letzten 14 Tage" wollen, sollte das ein Query sein, kein Skript, das durch Seiten blättert.

Drittens: Hohe Schreib- und Lese-Last ohne Drosselung verkraften. Sobald mehrere Workflows parallel laufen, summieren sich die API-Calls, und Sie stoßen schneller an Grenzen, als Sie glauben.

Notion hat in allen drei Punkten Schwächen.

Webhooks: kein vollständiger Pfad

Notion hat Webhooks erst Ende 2024 nachgereicht, und sie sind seither nur eingeschränkt brauchbar. Block-Änderungen innerhalb einer Seite werden nur teilweise abgebildet, und die Konfiguration der Subscriptions ist nicht so granular, wie Sie es von HubSpot, Stripe oder einer Postgres-Datenbank gewohnt sind.

Für viele Automatisierungen läuft es deshalb in der Praxis so: Make oder n8n pollt die Notion-Datenbank alle fünf Minuten. Das funktioniert eine Weile. Bis Sie 25 Datenbanken haben und 30 Workflows. Dann sind das schnell 8.000 Polling-Anfragen pro Tag, nur um Änderungen zu erkennen, die andere Systeme längst über Webhooks gemeldet hätten.

Die API ist nicht für Automatisierung gebaut

Die Notion-API ist primär eine Content-API. Sie ist exzellent darin, Seiten als Blöcke zu lesen und zu schreiben. Sie ist mäßig darin, Datenbanken so abzufragen, wie Sie es in einer Automatisierung erwarten.

Drei konkrete Beispiele.

Filterausdrücke sind begrenzt. Komplexere Verschachtelungen, mehrere AND/OR mit Bedingungen über verschiedene Property-Typen, funktionieren entweder nicht oder werden ohne Fehlermeldung still anders interpretiert. Ich habe Workflows debuggt, in denen ein Filter "Status = abgeschlossen UND Erstellt vor sieben Tagen" leise auch Einträge mit Status "in Arbeit" zurückgab, weil die Notion-API einen Edge Case anders auflöste, als ich erwartet hatte.

Property-Typen sind brüchig. Eine Spalte vom Typ "Formel" lässt sich nicht zuverlässig per API beschreiben. Eine Spalte vom Typ "Rollup" auch nicht. Eine Spalte vom Typ "Beziehung" nur, wenn die Ziel-IDs bereits bekannt sind. Wer mit Notion automatisiert, lernt schnell, welche Property-Typen man besser meidet, weil die API sie ignoriert oder Fehler wirft.

Das Rate Limit ist niedrig. Notion erlaubt etwa drei API-Calls pro Sekunde pro Integration. Klingt nach viel, ist es nicht, sobald Sie Schleifen über mehrere hundert Datensätze laufen lassen. Ein einfacher Sync-Job, der 500 Einträge synchronisiert, braucht in der Praxis dreieinhalb Minuten, davon zweieinhalb Minuten Wartezeit. Für Live-Synchronisation ist das ungeeignet.

Notion ist eine Sicht, keine Quelle

Das ist der wichtigste Punkt, und er ist konzeptionell.

Die meisten Notion-Setups, die ich sehe, vermischen zwei Dinge, die sauber getrennt gehören: das System of Record, also wo die Wahrheit liegt, und das System of Engagement, also wo Menschen damit arbeiten.

Notion ist gut als System of Engagement. Eine Vertriebsmitarbeiterin mag ein gut gebautes Notion-Board mit ihren Leads. Ein Projektmanager findet seine Roadmap in Notion übersichtlicher als in Jira.

Aber als System of Record, also als Quelle, der Ihre Workflows, Reports und Integrationen vertrauen, hat Notion keine Stärken, sondern nur Bequemlichkeit. Und Bequemlichkeit ist die teuerste Eigenschaft, die eine zentrale Datenquelle haben kann, weil sie alle anderen Probleme verdeckt, bis sie zu groß werden.

Die typische Sackgasse

Der Verlauf, den ich immer wieder sehe:

Phase 1, Begeisterung. Ein Team baut zwei oder drei Notion-Datenbanken, verlinkt sie über Beziehungen, automatisiert kleine Dinge mit Make. Es funktioniert. Alle sind zufrieden.

Phase 2, Wachstum. Aus drei Datenbanken werden zwölf. Aus drei Workflows werden zwanzig. Die Datenbanken werden voneinander abhängig, und die Workflows hängen quer drüber.

Phase 3, Reibung. Filter brauchen plötzlich Workarounds. Einzelne Workflows fallen still aus, weil Property-Typen geändert wurden. Make wirft Rate-Limit-Fehler. Niemand weiß mehr, welche Datenbank der "echte" Kundenstamm ist, weil drei Stück existieren, die sich gegenseitig syncen sollen.

Phase 4, Fragmentierung. Mitarbeiter beginnen, Excel-Tabellen daneben zu führen, weil die Notion-Sicht zu langsam ist. Daten driften auseinander. Reports widersprechen sich. Und irgendwann fragt jemand: "Was ist eigentlich unsere Datenbasis?"

Genau hier hört Notion auf, zu helfen.

Was stattdessen funktioniert

Ich sage Kunden in der Regel: Behalten Sie Notion für das, wofür es gut ist. Aber bauen Sie die Schicht darunter sauber.

Konkret heißt das, je nach Kontext.

Ein dediziertes CRM für Kunden- und Vertriebsdaten. HubSpot, Pipedrive, Attio, oder bei Open-Source-Präferenz EspoCRM. Diese Systeme haben echte Webhooks, vernünftige Filter, höhere Rate Limits und eine Datenstruktur, die für Vertriebsprozesse gebaut ist. Notion bekommt eine Read-Only-Sicht über eine Synced-Database oder eine Embed-Lösung, falls Mitarbeiter dort weiter arbeiten wollen.

Eine richtige Datenbank für strukturierte Geschäftsdaten. Postgres oder Supabase, dazu ein leichtes Frontend wie NocoDB oder Baserow für Mitarbeiter, die eine tabellenähnliche Oberfläche brauchen. Klingt aufwendig, ist es nicht. Ein Supabase-Projekt steht in zwei Stunden, und die API ist deutlich besser als die von Notion.

Airtable für mittlere Komplexität. Wenn Sie eine tabellenzentrische Datenwelt haben, in der eine echte Datenbank zu viel des Guten wäre, ist Airtable der bessere Mittelweg. Bessere API, bessere Filter, höhere Rate Limits, zuverlässige Webhooks.

Notion bleibt als Wiki, internes Handbuch, Meeting-Notizen, Projektübersichten. Da ist es konkurrenzlos.

Wann Notion doch passt

Damit der Artikel nicht einseitig wirkt: Es gibt Setups, in denen Notion als zentrale Quelle vollkommen ausreicht.

• Teams unter zehn Personen mit weniger als fünf parallelen Workflows.
• Use Cases, in denen Latenz egal ist. Ein Workflow, der einmal nachts läuft, kommt mit den Rate Limits zurecht.
• Reine Content- oder Wissensprozesse, in denen Notion sowieso die richtige Heimat ist: Blog-Drafts, Newsletter-Pipelines, Help-Center-Artikel.

In diesen Fällen ist es ein vernünftiger Default. Sobald Sie aber spüren, dass Workflows immer wieder an Notion-Grenzen stoßen, ist das ein klares Signal, die Architektur zu überdenken, bevor Sie die elfte Datenbank hinzufügen.

Die ehrliche Empfehlung

Wenn Sie heute am Anfang stehen und überlegen, ob Notion Ihre zentrale Datenquelle für Automatisierung wird, denken Sie zwei Schritte voraus.

Fragen Sie sich: Was passiert, wenn das Volumen sich verdreifacht? Wenn drei Mitarbeiter dieselbe Datenbank gleichzeitig bearbeiten? Wenn Sie ein zweites System anschließen wollen, das auch Live-Updates braucht? Wenn ein Workflow in der Mitte einer Schleife mit Rate-Limit-Fehler abbricht?

Wenn Sie darauf keine zufriedenstellende Antwort haben, ist Notion nicht die richtige Stelle für diese Daten. Nicht heute, und auch nicht in einem Jahr.

Das ist keine Schmähung. Notion ist gut in seinem Kernbereich. Es ist nur kein Datenbankprodukt, und so sollte man es auch nicht behandeln.

Wer prüfen möchte, ob die eigene Datenarchitektur den nächsten Wachstumsschritt trägt, bekommt im kostenlosen Automations-Check in etwa 30 Minuten ein klares Bild.