Nextcloud Custom Properties: Eigene Felder, echte Metadaten – und die Frage nach dem Speicherort

Wer in der Nextcloud eigene Informationen an Dateien, Personen oder Termine hängen möchte, stößt früher oder später auf den Begriff „Custom Properties“. Nur: Ein einheitliches Feature dieses Namens existiert nicht. Was existiert, ist ein Bündel unterschiedlicher Mechanismen, die je nach Ebene völlig anders funktionieren – technisch, organisatorisch und nicht zuletzt rechtlich. Wer sein Ablagesystem darauf aufbauen will, sollte diese Unterschiede kennen, bevor die ersten zehntausend Objekte mit selbstdefinierten Feldern befüllt sind.

Ein Begriff, viele Baustellen

Nextcloud ist kein Dokumentenmanagementsystem im klassischen Sinn, auch wenn es in vielen Unternehmen genau so eingesetzt wird. Diese Doppelrolle erklärt, warum der Wunsch nach eigenen Feldern so hartnäckig ist: Wer Akten digital ablegt, will Aktenzeichen, Mandantennummern, Vertragsarten, Prüfvermerke oder Ablaufdaten strukturiert erfassen – nicht als Freitext in einem Notizfeld, sondern als auswertbare Eigenschaft. Ein DMS wie d.3, ELO oder Alfresco liefert das ab Werk. Nextcloud liefert es in Bruchstücken.

Dabei zeigt sich eine Eigenheit, die in der Praxis immer wieder zu Missverständnissen führt: Custom Properties sind in Nextcloud kein einheitliches Objekt, sondern treten auf mindestens vier Ebenen auf. Auf der Ebene der Benutzerprofile gibt es sie als administrativ konfigurierbare Felder. Auf der Ebene der Dateien existieren sie als ausgelesene Metadaten aus dem Dateiinhalt – etwa EXIF, IPTC oder ID3 – sowie als Tags unterschiedlichster Herkunft. Auf der Systemebene wiederum sind beinahe alle Konfigurationswerte letztlich nichts anderes als Schlüssel-Wert-Paare in einer Datenbanktabelle. Und in der Groupware schließlich kennt man sie als X-Properties in vCard- und iCalendar-Dateien, also als Erweiterungsfelder, die Standards bewusst offenlassen.

Diese vier Ebenen haben wenig gemeinsam. Sie speichern an unterschiedlichen Orten, sie werden über unterschiedliche Schnittstellen angesprochen, und sie überleben einen Umzug der Dateien unterschiedlich gut. Genau darin liegt das eigentliche Problem, und genau darum lohnt sich eine sortierte Betrachtung.

Profilfelder: eigene Eigenschaften für Personen

Am sichtbarsten und am besten dokumentiert ist der Bereich, den Nextcloud selbst „Profil“ nennt. Administratoren können dort unter den Verwaltungseinstellungen zusätzliche Felder anlegen – Telefonnummern, Abteilungen, Standorte, Kostenstellen, Eintrittsdaten, was auch immer der Betrieb braucht. Zur Verfügung stehen verschiedene Feldtypen: einzeiliger Text, mehrzeiliger Text, Datum, Ja/Nein-Schalter, Auswahlfelder, Mehrfachauswahl und Felder, die mehrere Werte desselben Typs aufnehmen. Der Feldtyp bestimmt nicht nur die Eingabemaske, sondern auch, wie sich der Wert später suchen und sortieren lässt.

Interessant ist die Sichtbarkeitslogik. Jedes Feld erhält einen Geltungsbereich, der festlegt, wer den Inhalt sehen darf. Die Spanne reicht von „nur ich“ über „nur lokal bekannte Nutzer“ bis zu „öffentlich“ und „über Föderation hinweg sichtbar“. Letzteres ist mehr als eine Spielerei: In Verbünden mehrerer Nextcloud-Instanzen, wie sie in Hochschulen oder Konzernverbänden durchaus vorkommen, lassen sich darüber Kontaktinformationen kontrolliert über Instanzgrenzen hinweg teilen. Man sollte sich allerdings darüber im Klaren sein, dass ein einmal freigegebenes Feld auch tatsächlich abrufbar ist – die Sichtbarkeitsstufen sind keine Verschlüsselung, sondern Zugriffslogik.

Wer Nextcloud mit LDAP oder Active Directory betreibt, kann einen Teil dieser Profilfelder aus dem Verzeichnisdienst befüllen. Das ist praktisch, weil die Personalabteilung dann weiterhin die Hoheit über die Stammdaten behält. Es ist aber auch eine Quelle stiller Fehler: Wenn die Zuordnung zwischen Verzeichnisattribut und Profilfeld nicht sauber gepflegt wird, überschreibt die Synchronisation mühsam von Hand gepflegte Zusatzinformationen. In der Praxis bewährt hat sich eine klare Trennung – alles, was aus dem Verzeichnis kommt, ist dort die Wahrheit; alles, was nur in Nextcloud lebt, bleibt in Nextcloud und wird nicht synchronisiert.

Datei-Metadaten: was die Datei selbst mitbringt

Die zweite Ebene ist die technisch reizvollste, weil sie ohne manuelle Eingabe funktioniert. Die Metadata-App für Nextcloud liest Informationen aus, die ohnehin in den Dateien stecken: Aufnahmedatum, Kamera, Blende, ISO-Wert, GPS-Koordinaten bei Bildern, Titel, Interpret und Albuminformationen bei Audiodateien, dazu die üblichen XMP- und IPTC-Blöcke, die Bildagenturen und Redaktionssysteme seit Jahren verwenden. Diese Werte werden beim Hochladen oder beim Indexierungslauf extrahiert und in der Datenbank abgelegt – die Originaldatei bleibt unangetastet.

Der Vorteil liegt auf der Hand. Eine Fotoredaktion kann nach Bildern suchen, die mit einer bestimmten Kamera und innerhalb eines Zeitfensters am Standort X entstanden sind, ohne dass jemand Schlagworte vergeben musste. Im Bauwesen, in der Immobilienverwaltung oder in der Dokumentation technischer Anlagen ist das oft der einzige Weg, große Bildbestände überhaupt erschließbar zu machen. Auch die Fotos-App nutzt diese Informationen für ihre zeitliche und örtliche Gruppierung.

Die Grenzen sind allerdings eng gesteckt. Ausgelesen wird nur, was im Dateiformat vorgesehen ist, und nur für Dateitypen, für die die App einen Parser mitbringt. Ein PDF mit ausgefülltem Formular, eine Tabelle mit Vertragsnummern in Spalte F, ein gescanntes Schreiben ohne OCR – all das liefert nichts. Wer eigene Felder jenseits des Standards braucht, kommt hier nicht weiter. Ein zweiter Punkt wiegt schwerer: Die extrahierten Werte liegen ausschließlich in der Nextcloud-Datenbank. Wird die Datei per WebDAV oder SMB auf einen anderen Server kopiert, ist die Information weg. Metadaten sind in dieser Architektur ein Index, kein Bestandteil der Datei.

Eigene Felder an Dateien: der schwierige Teil

Und damit zum wunden Punkt. Wer in Nextcloud ein frei definierbares Feld wie „Aktenzeichen“ oder „Rechnungsdatum“ direkt an eine Datei hängen will, sucht in der Standardinstallation vergeblich. Anders als bei Profilfeldern gibt es keine Verwaltungsoberfläche, in der man Dateifelder anlegt, benennt, mit Datentypen versieht und für bestimmte Ordner verpflichtend macht. Die Community fordert das seit Jahren, die Umsetzung ist in Teilen vorhanden, aber fragmentiert – je nach Version, je nach installierten Apps, je nachdem, ob eine Enterprise-Variante im Spiel ist.

Nicht zuletzt deshalb hat sich in der Praxis ein Bündel von Behelfen etabliert, das man kennen sollte. Der erste und ehrlichste ist der Verzicht: Man akzeptiert, dass Nextcloud kein DMS ist, und verlagert strukturierte Daten in eine Fachanwendung, die lediglich auf die Datei verlinkt. Das ist unspektakulär, aber oft die betriebswirtschaftlich vernünftigste Lösung.

Der zweite Behelf ist die Enkodierung im Dateinamen oder in der Ordnerstruktur. So unschön das klingt, so robust ist es: Ein Schema wie 2024-0198_Mandant4711_Vertrag_2024-03-15.pdf überlebt jede Migration, jede Freigabe, jeden Sync auf das Smartphone. Der Preis ist offensichtlich – Umbenennungen brechen die Logik, lange Namen stoßen an Pfadgrenzen, und eine echte Datenbankabfrage wird daraus nie.

Der dritte Behelf arbeitet mit Tags, und er verdient einen eigenen Abschnitt, weil er in der Realität die wichtigste Rolle spielt.

Tags als pragmatische Alternative

Nextcloud unterscheidet zwischen persönlichen Tags und System-Tags. Persönliche Tags gehören dem jeweiligen Benutzer, sind farbig und frei benennbar – nützlich für die eigene Ablage, aber nicht steuerbar. System-Tags dagegen werden administrativ verwaltet, können bestimmten Gruppen zugewiesen oder entzogen werden und lassen sich in Workflows, Zugriffsregeln und Suchen verwenden. Für alles, was organisatorisch verbindlich sein soll, sind sie die richtige Wahl.

Ein System-Tag ist im Kern nichts anderes als eine Eigenschaft ohne Wert – eine Markierung, die entweder gesetzt ist oder nicht. Mehrere Tags an einem Objekt ergeben dann eine Kombination, über die sich sehr wohl komplexe Sachverhalte abbilden lassen: Vertrag, gekündigt, Mandant 4711, Archiv 2031. Die Nextcloud-Suche versteht solche Kombinationen, und die Dateiliste lässt sich danach filtern.

So elegant das klingt, so schnell wächst es einem über den Kopf. Die Automatische-Tagging-App kann Regeln definieren, die beim Upload greifen – etwa „alles mit Endung .dwg bekommt das Tag CAD“, oder „alles aus Ordner /Eingang/Projekte/ bekommt das Tag Projekt“. Das ist nützlich. Es ist aber auch ein bekannter Weg in die Datenbankexplosion: Jede einzelne Tag-Zuweisung erzeugt einen Datensatz in der Zuordnungstabelle. Werden Regeln so gebaut, dass sie für jedes Dokument ein eigenes, dynamisch erzeugtes Tag vergeben, produziert man in wenigen Monaten Hunderttausende von Zeilen, die jede Suche verlangsamen und den Backupumfang aufblähen. Tags sind ein Werkzeug für kontrollierte Vokabulare, nicht für Freitext.

Systemebene: appconfig, occ und config.php

Die dritte Ebene betrifft Administratoren. In Nextcloud ist praktisch jede Anwendungseinstellung ein Schlüssel-Wert-Paar in einer Datenbanktabelle namens oc_appconfig. Dasselbe gilt für die Systemkonfiguration, die in der config.php liegt und über occ config:system:set verändert werden kann. Aus technischer Sicht sind das Custom Properties auf Systemebene – frei definierbare Schlüssel, die Anwendungen und Skripte abfragen können.

Werkzeuge wie occ config:app:set, occ config:app:get und occ config:app:delete gehören deshalb zum Standardrepertoire jeder Installation. Man kann damit etwa Standardwerte für eine App hinterlegen, Feature Flags setzen oder Werte aus einer Automatisierung heraus pflegen. In der Praxis werden diese „Properties“ allerdings allzu oft zweckentfremdet: als halb dokumentierte Sammlung von Sonderfällen, die irgendwann niemand mehr zuordnen kann. Wer hier arbeitet, sollte sich angewöhnen, jede Änderung zu notieren – in einem Änderungsprotokoll, nicht im Gedächtnis. occ config:list zeigt den aktuellen Stand, und der ist bei gewachsenen Instanzen regelmäßig erhellend.

Wichtig für Betreiber: Diese Werte leben ausschließlich in der Datenbank beziehungsweise in der Konfigurationsdatei. Ein Restore, das nur die Dateiablage zurückspielt, stellt sie nicht wieder her. Das klingt banal, ist aber in der Praxis eine der häufigsten Ursachen für „nach dem Umzug funktioniert nichts mehr“.

WebDAV und APIs: der Blick von außen

Für Integrationen ist entscheidend, wie sich Eigenschaften über Schnittstellen lesen und schreiben lassen. Nextcloud spricht WebDAV, und die Datei-Properties, die dabei ausgeliefert werden, sind seit Jahren stabil: Dateigröße, Änderungsdatum, ETag, Datei-ID, System-Tags als eigene Namensraum-Eigenschaft. Interessant ist, dass WebDAV grundsätzlich auch benutzerdefinierte Eigenschaften kennt – jene „dead properties“, die ein Server einfach speichern soll. Wie weit eine Nextcloud-Instanz das tatsächlich tut, hängt von Version und Anwendungskontext ab; für Dateien ist die Unterstützung traditionell eingeschränkt, während Kalender und Adressbücher über SabreDAV mehr Spielraum bieten. Wer darauf aufbauen will, sollte das vorab mit einem PROPFIND- und PROPPATCH-Test gegen die eigene Instanz verifizieren, statt sich auf Blogbeiträge zu verlassen.

Daneben steht die OCS-Schnittstelle für Verwaltungsaufgaben sowie die inzwischen recht ordentlichen HTTP-APIs der einzelnen Apps. Für die Profilebene gibt es Endpunkte, über die sich Profildaten lesen und – mit den passenden Rechten – auch schreiben lassen. Damit lassen sich Personalstammdaten aus einer HR-Anwendung heraus aktualisieren, ohne dass jemand die Weboberfläche anfasst. Solche Integrationen sind der Punkt, an dem Custom Properties ihren eigentlichen Nutzen entfalten: nicht als hübsche Zusatzfelder in einer Maske, sondern als Datenpunkte in einem übergreifenden Prozess.

Tables: wenn aus Eigenschaften ein Datenmodell wird

Eine vergleichsweise junge Antwort auf die Feldermisere ist die Tables-App. Sie erlaubt es, eigene Tabellen mit Spalten verschiedener Typen anzulegen – Text, Zahl, Datum, Auswahl, Verknüpfung auf andere Tabellen – und diese Tabellen mit Benutzern oder Gruppen zu teilen. Man kann damit strukturierte Verzeichnisse führen: eine Inventarliste, eine Projektübersicht, ein Schulungsverzeichnis, ein Kontaktregister mit eigenen Feldern.

Der Vorzug liegt in der Konsequenz des Modells. Statt Eigenschaften lose an Dateien zu hängen, definiert man ein Datenobjekt und verknüpft es mit Dateien oder Personen. Die App ist noch nicht in jeder Hinsicht ausgereift – Import, Massenbearbeitung und Berichtsfunktionen sind schmaler als in ausgewachsenen Datenbankanwendungen –, aber für viele mittelgroße Anwendungsfälle ist sie genau das fehlende Bindeglied zwischen Dateiablage und strukturierter Information. Wer heute eine Nextcloud als leichtes DMS betreibt, sollte Tables ernsthaft prüfen, bevor er sich auf selbstgebaute Konstrukte aus Tags und Dateinamen einlässt.

Workflow und Zugriffskontrolle: Eigenschaften als Steuerung

Besonders spannend wird die Sache, wenn Eigenschaften nicht nur beschreiben, sondern steuern. Die Workflow-Engine von Nextcloud ist eine Regelmaschine, die auf Ereignisse reagiert – Upload, Download, Update, Löschen – und Bedingungen prüft. Zu den prüfbaren Merkmalen gehören Dateiname, Dateityp, Größe, Gruppenzugehörigkeit des Nutzers, IP-Bereich, Uhrzeit und eben auch Tags. Daraus lassen sich Zugriffsregeln bauen, die über die klassische Ordnerfreigabe hinausgehen.

Ein Beispiel aus der Praxis: Eine Kanzlei möchte, dass Dokumente, die als vertraulich markiert sind, nur aus dem Kanzleinetz heruntergeladen werden dürfen. Statt für jede Mandatsmappe eigene Rechte zu pflegen, vergibt die automatische Tagging-Regel beim Upload das Tag vertraulich, und die Zugriffskontrolle verbietet anschließend jeden Download außerhalb definierter IP-Bereiche. Solche Konstrukte sind deutlich wartungsärmer als gewachsene Rechtestrukturen – vorausgesetzt, die Tag-Vergabe selbst ist verlässlich und die Regeln widersprechen sich nicht.

Genau dort liegt das Risiko. Regelwerke, die sich gegenseitig überschreiben, sind in größeren Installationen ein reales Problem, und Nextcloud macht es einem nicht leicht, sie zu überblicken. Es empfiehlt sich dringend, Workflow-Regeln zu dokumentieren, mit Testgruppen einzuführen und nach jeder Aktualisierung der Instanz zu überprüfen. Manche Regeln verhalten sich zwischen Hauptversionen subtil anders; wer das ignoriert, erzeugt Sicherheitslücken, die niemandem auffallen, bis es zu spät ist.

Groupware: X-Properties in vCard und iCalendar

Die vierte Ebene ist die unspektakulärste und zugleich die interoperabelste. Sowohl vCard als auch iCalendar sind Standards, die ausdrücklich Erweiterungsfelder vorsehen – Eigenschaften, deren Name mit X- beginnt. Adressbuch- und Kalenderserver sollen solche Felder unverändert durchreichen, auch wenn sie ihren Inhalt nicht verstehen. Das ist der Grund, warum sich Zusatzinformationen aus CRM-Systemen relativ zuverlässig über CardDAV und CalDAV transportieren lassen.

In der Praxis heißt das: Wer Kontaktdaten zwischen einer Nextcloud und einer Fachanwendung abgleicht, kann eigene Felder mitführen, sofern beide Seiten sich auf Namen und Format einigen. Innerhalb der Nextcloud-Oberfläche sind diese Felder dann allerdings meist unsichtbar. Die Contacts-App zeigt sie nicht ohne Weiteres an, und die Kalender-App schon gar nicht. Wer darauf setzt, sollte sich vor Augen führen, dass der Nutzer in der Weboberfläche nur einen Teil der Wahrheit sieht – eine Konstellation, die bei Supportfällen regelmäßig für Verwirrung sorgt.

Betrieb: Datenbank, Suche, Performance

Custom Properties sind bequem, solange sie wenige sind. Sobald sie in großem Stil eingesetzt werden, verschiebt sich die Last vom Dateisystem in die Datenbank. Metadatenwerte, Tag-Zuordnungen und Profilfelder liegen in eigenen Tabellen, die bei jeder Suche, jeder Dateiliste und jedem Sync mitgelesen werden. Eine Instanz mit mehreren Millionen Dateien und einem Zehntel davon mit Zusatzinformationen reagiert deutlich träger als eine reine Dateiablage.

Drei Maßnahmen helfen zuverlässig. Erstens: Tags und Eigenschaften sparsam und mit kontrolliertem Vokabular einsetzen. Wer für jedes Projekt ein eigenes Tag anlegt und tausend Projekte hat, hat ein Problem. Zweitens: Die Datenbank ordentlich dimensionieren. MariaDB oder PostgreSQL mit ausreichend Arbeitsspeicher und korrekt gesetzten Indizes sind Pflicht; wer Nextcloud mit SQLite betreibt, sollte von strukturierten Eigenschaften im größeren Umfang Abstand nehmen. Drittens: Für Volltextsuche über Dateiinhalte und Metadaten eine dedizierte Suchmaschine einsetzen – die Full-Text-Search-App mit Elasticsearch oder OpenSearch –, statt sich auf die eingebaute Datenbanksuche zu verlassen. Das kostet Ressourcen, spart aber spürbar Nerven.

Ein interessanter Aspekt ist die Wechselwirkung mit der Dateiversionierung und dem Papierkorb. Metadaten hängen an der Datei-ID, nicht am Dateinamen. Wird eine Datei umbenannt oder verschoben, bleiben ihre Eigenschaften erhalten; wird sie gelöscht und neu hochgeladen, entsteht eine neue ID und die Eigenschaften sind fort. Wer versehentlich das falsche Objekt bearbeitet hat, kann das nicht rückgängig machen – hier hilft nur ein sauberes Prozessdesign mit möglichst wenigen manuellen Eingriffen.

Sicherheit, Datenschutz und Governance

Sobald Eigenschaften personenbezogene Daten enthalten, greift die Datenschutzlogik. Ein Profilfeld mit privater Mobilnummer, ein GPS-Tag an einem Foto aus dem Homeoffice, ein Freitextfeld mit gesundheitlichen Hinweisen im Kontaktformular – all das sind Verarbeitungen, die einer Rechtsgrundlage bedürfen und in einem Verzeichnis der Verarbeitungstätigkeiten auftauchen sollten. Nextcloud liefert dafür keine fertige Governance, sondern nur die Bausteine. Die Pflicht zur Dokumentation liegt beim Betreiber.

Ein besonders heikler Punkt sind die Metadaten in Bildern. GPS-Koordinaten in Fotos können Bewegungsprofile erzeugen, und zwar von Personen, die nie zugestimmt haben. In Organisationen, die Fotos veröffentlichen – Kommunen, Vereine, Medienhäuser –, gehört deshalb eine Strategie dazu, wie mit diesen Geo-Daten umgegangen wird. Die Metadata-App kann Werte auslesen, aber sie entfernt sie nicht. Wer Bilder extern weitergibt, sollte vorab prüfen, ob die Koordinaten noch in der Datei stehen.

Auch die Sichtbarkeit von Profilfeldern ist ein Governance-Thema. Bei jeder Konfiguration sollte man sich die Frage stellen, wer das Feld später sieht – nicht nur heute, sondern auch nach einer Änderung der Sichtbarkeitsstufe. Es ist erstaunlich, wie häufig in Organisationen Felder auf „öffentlich“ stehen, weil das bei der Einführung bequem war und nie jemand nachgefragt hat.

Vier Szenarien aus der Praxis

Ein Ingenieurbüro archiviert Projektfotos über Jahre. Kamera, Aufnahmedatum und Standort kommen über die Metadata-App automatisch mit, die Projektzuordnung über einen Ordner und ein System-Tag. Für die Dokumentation genügt das; ein eigenes Feld „Bauteil“ pflegt man in der Projektsoftware und verlinkt die Bilder dorthin. Der Aufwand in Nextcloud bleibt minimal.

Eine Steuerberatung will Mandantenzuordnung, Steuerart und Jahr. Nextcloud allein wäre dafür das falsche Werkzeug. Hier passt eine Tables-Tabelle mit Mandantennummer und eine Ordnerstruktur, die dieselbe Nummer im Namen führt. Die strukturierte Auswertung übernimmt die Fachanwendung, die Datei verlinkt nur.

Ein kommunaler Betrieb braucht ein Schulungsverzeichnis mit Zertifikaten, Ablaufdaten und Standorten. Profilfelder liefern Abteilung und Standort, eine Tables-Tabelle die Zertifikate samt Ablaufdatum. Die Erinnerung vor Ablauf muss extern erfolgen – dafür gibt es die API, die eine kleine Anwendung nutzt.

Eine Hochschule wiederum lebt von der Föderation. Sichtbarkeitsstufen in den Profilfeldern sorgen dafür, dass E-Mail und Rolle instanzübergreifend auffindbar sind, interne Angaben es nicht sind. Das ist einer der wenigen Bereiche, in denen Nextclouds Umsetzung wirklich gut durchdacht ist.

Backup, Migration und das Problem mit der Portabilität

Am Ende läuft alles auf eine schlichte Merkregel hinaus: In der Nextcloud sind Eigenschaften nicht Teil der Datei. Sie sind Einträge in einer Datenbank, die man nur gemeinsam mit dieser Datenbank sichern, umziehen und wiederherstellen kann. Wer seine Instanz per rsync auf einen anderen Server spiegelt, überträgt Dateien, aber keine Metadaten.

Für Umzüge zwischen Systemen hilft ein Umweg über das Dateiformat selbst. ExifTool kann Bild- und Audiodateien mit XMP- und IPTC-Blöcken beschreiben, sodass die Information tatsächlich in der Datei reist. Manche Organisationen schreiben deshalb beim Export systematisch Sidecar-Dateien oder ein XMP-Paket. Das ist Handarbeit, aber es ist der einzige Weg, der auch nach einem Wechsel des Anbieters noch funktioniert.

Der gleiche Grundsatz gilt für Profil-, Tag- und Konfigurationsdaten. Ein vollständiges Backup umfasst die Datenbank, das Datenverzeichnis, die config.php und – je nach Umfang – die Anwendungsverzeichnisse. Erst diese Kombination ergibt eine Instanz, die sich wirklich wiederherstellen lässt.

Fazit: ein Werkzeugkasten, kein Werkzeug

Nextcloud wird den Wunsch nach Custom Properties nicht vollständig erfüllen. Dafür fehlt die einheitliche, administrative und portable Umsetzung, die ein professionelles DMS auszeichnet. Was die Plattform stattdessen bietet, ist ein ganzer Werkzeugkasten: gut gemachte Profilfelder, brauchbare automatische Metadatenextraktion, mächtige System-Tags, eine flexible Workflow-Engine, eine junge Tabellen-App und offene Schnittstellen, über die sich fast alles anbinden lässt.

Wer das ernsthaft nutzen will, sollte vor der ersten Konfiguration entscheiden, welche Information an welcher Stelle die Wahrheit ist. Dokumenteigenschaften gehören in die Fachanwendung, Personenfelder ins Verzeichnis, Struktur in die Tags, sensible Zusatzdaten in die Datenbank – und alles, was die Organisation überleben soll, in ein Format, das auch ohne Nextcloud noch lesbar ist. Diese Entscheidung ist wichtiger als jede Einstellung. Sie zu treffen ist Arbeit, aber es ist die Art von Arbeit, die man einmal macht und dann jahrelang davon profitiert – Standart hin oder her.