Es gibt Sätze, die in deutschen IT-Abteilungen so verlässlich fallen, dass man sie an der Betonung erkennt: „Wir müssen da irgendwie raus.“ Gemeint ist selten die Cloud an sich – gemeint ist die Abhängigkeit. Von Lizenzen, von Preisrunden, von einer Datenhaltung, deren Route man nicht selbst zeichnet. Und in genau dieser Gemengelage ist Nextcloud zu einer Art Standardantwort geworden, jedenfalls im deutschsprachigen Raum häufiger als anderswo.
Wer heute eine Nextcloud aufsetzt, bekommt allerdings kein reines Filesharing mehr. Das war einmal, irgendwann zwischen 2016 und dem ersten „Hub“-Release. Heute ist das Produkt eine Plattform, auf der Dateien, Kalender, Kontakte, Chat, Videokonferenzen, Office-Dokumente und eine dreistellige Zahl von Zusatzanwendungen zusammenlaufen. Und weil Plattformen erfahrungsgemäß dazu neigen, sich auszudehnen, stellt sich früher oder später die Frage, was man eigentlich noch dazukauft. Etwa ein CRM. Etwa Insightly.
Genau dort wird es interessant. Denn die Kombination aus einer selbst betriebenen Kollaborationsplattform und einem amerikanischen SaaS-CRM ist kein Widerspruch, sondern eine ziemlich typische Realität in mittelständischen Unternehmen – und sie hat Fallstricke, die man kennen sollte, bevor man sie eingeht.
Vom Fork zur Infrastruktur
Die Vorgeschichte ist bekannt, aber sie erklärt, warum Nextcloud heute so aussieht, wie es aussieht. 2016 spaltete Frank Karlitschek das ownCloud-Projekt und gründete mit einem guten Teil der damaligen Belegschaft die Nextcloud GmbH mit Sitz in Stuttgart. Der Bruch war unschön, hatte aber einen Nebeneffekt: Nextcloud konnte von Anfang an als Unternehmen gedacht werden – mit Releasezyklen, Supportverträgen und einer klaren Vorstellung davon, wer die Zielgruppe ist. Nämlich nicht nur Privatnutzer mit einem Raspberry Pi, sondern Verwaltungen, Hochschulen, Kliniken und Firmen, die aus regulatorischen oder strategischen Gründen nicht in eine Hyperscaler-Umgebung ziehen wollen oder dürfen.
Technisch ist Nextcloud im Kern ein PHP-Monolith, der auf einem klassischen LAMP- oder LEMP-Stack läuft. Als Datenbanken werden MariaDB, MySQL, PostgreSQL und für sehr kleine Installationen SQLite unterstützt. Das klingt konservativ, fast altmodisch, und das ist es auch – aber genau diese Bodenständigkeit macht den Betrieb berechenbar. Wer schon einmal einen PHP-Stack über Jahre gepflegt hat, weiß ungefähr, was ihn erwartet: PHP-FPM-Worker, OPcache, ein bisschen Redis für File-Locking und Caching, dazu ein Webserver. Kein Hexenwerk, aber auch nichts, was man mal eben nebenbei administriert.
Um die Kernanwendung herum liegt der eigentliche Reiz: das App-Ökosystem. Nextcloud spricht von mehreren hundert Apps, und auch wenn ein erheblicher Teil davon Spielerei, halbfertig oder schlicht verwaist ist, sind darunter Bausteine, die den Unterschied machen. Collabora Online oder OnlyOffice als Office-Suite im Browser. Talk für Chat, Audio- und Videokonferenzen. Deck für Kanban-Boards. Tables für strukturierte Datenbanken im Dateikontext. Forms für Umfragen und Formulare. Collectives als Wissensbasis. Dazu Groupware mit CalDAV und CardDAV, also Kalender, Kontakte, Aufgaben – kompatibel mit eigentlich jedem gängigen Client, sei es Outlook, Thunderbird, Apple Mail oder das Smartphone.
Betrieb: zwischen Einplatinenrechner und Cluster
Eine der Stärken von Nextcloud ist die Bandbreite der Betriebsmodelle. Auf der einen Seite steht das Snap-Paket, das auf Ubuntu-Servern in wenigen Minuten läuft und für kleine Teams durchaus brauchbar ist. Auf der anderen Seite stehen Kubernetes-Deployments mit Helm-Charts, mehreren PHP-Pods hinter einem Ingress, externer Objektspeicher-Anbindung und getrennter Datenbank. Dazwischen liegen die üblichen Verdächtigen: handinstalliert nach Dokumentation, als Docker-Compose-Stack oder mit dem offiziellen „All-in-One“-Container, der mittlerweile erstaunlich viel Automatik mitbringt und für viele Mittelständler der pragmatischste Weg ist.
Beim Speicher gibt es drei realistische Varianten. Die einfachste ist lokaler Blockstorage mit einem dateibasierten Filesystem, üblicherweise XFS oder ext4. Skalierbarer wird es mit einem Objektspeicher wie S3-kompatiblen Systemen, etwa Ceph, MinIO oder einem Cloud-Bucket. Und dazwischen liegt NFS, das häufig dann auftaucht, wenn eine bestehende NAS-Infrastruktur weitergenutzt werden soll. Wichtig ist die Unterscheidung zwischen „primary storage“, wo die eigentlichen Nutzdaten liegen, und dem, was Nextcloud selbst im Datenverzeichnis ablegt. Wer hier falsch plant, merkt es spätestens beim ersten Vollbackup.
Apropos Backup. Das ist in der Praxis der Punkt, an dem Nextcloud-Projekte am häufigsten scheitern. Die Datenbank und das Datenverzeichnis müssen konsistent zueinander gesichert werden – ein reiner Snapshot des Filesystems bei laufendem Betrieb liefert im Zweifel einen Zustand, der sich nicht sauber wiederherstellen lässt. Wer den Wartungsmodus scheut, sollte zumindest die Datenbank vor dem Snapshot in einen konsistenten Zustand bringen. Und dann kommt der Teil, den alle kennen und keiner übt: der Restore. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, keine Sicherung.
Beim Skalieren hilft es, die Flaschenhälse zu kennen. Erfahrungsgemäß sind das nicht die PHP-Prozesse, sondern die Datenbank, das Dateisystem und die Vorschaubildgenerierung. Gerade Letztere kann eine Installation mit vielen Bildern und Videos erheblich belasten. Der Nextcloud-eigene Cron-Job, der im Hintergrund arbeitet, sollte deshalb auf einen echten Systemcron umgestellt sein, nicht auf den AJAX-Modus. Klingt nach Detail, ist aber der Unterschied zwischen einer flotten und einer zähen Instanz.
Sicherheit ist kein Häkchen
Nextcloud bringt eine ganze Reihe von Sicherheitsfunktionen mit, und wer sie ignoriert, baut sich ein Problem, das später teuer wird. Zwei-Faktor-Authentifizierung über TOTP, WebAuthn oder Hardware-Token gehört heute zum Standard. Anbindung an LDAP oder Active Directory ebenfalls, wobei die Konfiguration der user_ldap-App nach wie vor zu den unterschätzten Aufgaben gehört – Gruppenzuordnungen, Filter und Mapping-Regeln sind selten beim ersten Versuch korrekt.
Für größere Umgebungen sind SAML oder OIDC über die entsprechenden Apps der übliche Weg. Damit lässt sich Nextcloud in eine bestehende Identity-Landschaft einhängen, idealerweise mit Single Sign-on und zentraler Rechtevergabe. Spannend ist die Frage, wie tief man das treibt. Denn je konsequenter die zentrale Identität, desto weniger Sonderfälle – aber auch desto größer die Abhängigkeit von dieser einen Komponente.
Bei der Verschlüsselung lohnt die Differenzierung, weil hier viel Halbwissen unterwegs ist. Transportverschlüsselung per TLS ist selbstverständlich. Serverseitige Verschlüsselung schützt die Daten im Ruhezustand, aber der Server kann sie im Betrieb lesen – was für Virenscan, Volltextsuche und Office-Bearbeitung notwendig ist. Ende-zu-Ende-Verschlüsselung schützt deutlich besser, hat aber Konsequenzen: kein serverseitiger Virenscan, keine serverseitige Suche, keine gemeinsame Bearbeitung im Browser. Für einzelne Ordner mit besonders sensiblen Inhalten ist das ein sinnvoller Kompromiss. Als Standard für eine ganze Instanz eher nicht.
Dazu kommen Bausteine, die im Alltag mehr bringen als so manche Chiffre-Diskussion: File Access Control, mit der sich Zugriffe regelbasiert einschränken lassen, etwa nach IP-Bereich, Gerätetyp oder Datei-Tag. Retention-Regeln, die alte Dateien automatisch löschen. Brute-Force-Schutz, Passwortrichtlinien, eine restriktive Content-Security-Policy. Und ein Audit-Log, das protokolliert, wer wann welche Datei geteilt, heruntergeladen oder gelöscht hat. In regulierten Umgebungen ist genau das oft der Punkt, an dem eine Lösung überhaupt erst zulässig wird.
Für öffentliche Auftraggeber und kritische Infrastrukturen kommt ein weiterer Aspekt hinzu: Wer betreibt die Instanz, wo stehen die Server, wie ist die Auftragsverarbeitung geregelt? Nextcloud lässt sich in einem Rechenzentrum in Deutschland betreiben, mit deutschen oder europäischen Dienstleistern, ohne dass Daten die Jurisdiktion verlassen. Das ist für viele Organisationen der eigentliche Grund für das Projekt – weniger die Lizenzkosten als die Frage, wer im Zweifel Zugriff hat.
Die API als Scharnier
Was Nextcloud interessant für Integrationsprojekte macht, ist die Breite der Schnittstellen. Nach außen ist da zunächst WebDAV, der klassische Weg auf Dateien. Dazu kommen die OCS-APIs, die Sharing, Benutzerverwaltung, Talk, Notifications und vieles mehr abdecken. Die Sharing-API etwa ist der saubere Weg, um programmatisch einen Freigabelink zu erzeugen, mit Passwort, Ablaufdatum und Abruflimit. Der Provisioning-Teil erlaubt es, Nutzer und Gruppen anzulegen – nützlich, wenn Nextcloud an ein anderes System gekoppelt werden soll.
Für Automatisierung innerhalb der Plattform gibt es Flow. Damit lassen sich Regeln definieren: Wenn eine Datei in einen bestimmten Ordner gelegt wird, dann tagge sie, verschiebe sie, benachrichtige jemanden oder führe ein Skript aus. In Kombination mit der Webhooks-App wird daraus ein Ereignisbus, der externe Systeme informiert. Wer ein CRM anbinden will, landet fast zwangsläufig hier.
Für tiefere Eingriffe gibt es das App-Framework. Nextcloud-Apps sind in PHP geschrieben, mit Vue im Frontend, und folgen einer inzwischen recht ordentlichen Dokumentation. Wer eigene Anwendungslogik direkt in die Plattform bringen will, kann das tun – sollte aber die Wartungsfrage mitdenken. Eine selbstgestrickte App bricht spätestens beim nächsten Major-Upgrade, wenn niemand mehr da ist, der sie pflegt.
CRM in Nextcloud: ehrlich betrachtet
Es gibt im Nextcloud-App-Store durchaus CRM-Anwendungen. Und es gibt Wege, EspoCRM oder Odoo anzubinden. Beides funktioniert, beides hat seine Berechtigung. Nur: An ein ausgewachsenes Vertriebssystem mit Pipelines, Forecast-Reports, Marketing-Automatisierung und einer gepflegten Oberfläche für Außendienstler reicht das in aller Regel nicht heran. Nextcloud ist gut darin, Dokumente zu verwalten, zu teilen und zu versionieren. Es ist weniger gut darin, einen Vertriebsprozess von der Erstansprache bis zum Abschluss abzubilden.
Das ist keine Schwäche, die man wegdiskutieren muss. Es ist eine Arbeitsteilung, die man akzeptieren kann. Und genau an diesem Punkt kommt ein Werkzeug wie Insightly ins Spiel.
Insightly: der pragmatische Gegenentwurf
Insightly ist ein cloudbasiertes CRM aus San Francisco, seit 2009 am Markt, ursprünglich mit einer engen Verbindung zu Google-Apps gestartet. Die Grundidee war immer dieselbe: ein CRM, das sich schnell einführen lässt, ohne dass man monatelang konfiguriert. Kontakte, Organisationen, Verkaufschancen, Projekte, Aufgaben, dazu E-Mail-Integration und Berichte. In den höheren Tarifen kommen Marketing-Funktionen, Workflow-Automatisierung und eine ausgeprägtere Anpassbarkeit dazu.
Die Stärke liegt im Einstieg. Wer eine Vertriebsmannschaft hat, die bisher in Excel und E-Mail lebt, kann mit Insightly innerhalb weniger Wochen produktiv arbeiten. Es gibt Import-Assistenten, vorgefertigte Pipelines, mobile Apps und eine Oberfläche, die auch Menschen bedienbar bleibt, die kein CRM studiert haben. Das sollte man nicht gering schätzen – der häufigste Grund für gescheiterte CRM-Projekte ist nicht die Technik, sondern die Akzeptanz.
Die technische Seite ist ebenfalls solide. Insightly bietet eine REST-API, über die sich im Wesentlichen alle Objekte lesen und schreiben lassen. Dazu kommen Webhooks, mit denen sich Änderungen ereignisgesteuert nach außen melden lassen, sowie Anbindungen an Automatisierungsplattformen wie Zapier oder Make. Damit ist Insightly kein geschlossener Kasten, sondern lässt sich in eine bestehende Systemlandschaft einfügen.
Die andere Seite der Medaille ist bekannt. Die Daten liegen in der Cloud des Anbieters, mit den üblichen Fragen nach Speicherort, Auftragsverarbeitung und Zugriffsrechten. Die Kosten skalieren pro Nutzer, was bei wachsendem Team spürbar wird. Und tiefergehende Anpassungen stoßen irgendwann an Grenzen, weil man eben nicht im Quellcode arbeitet, sondern in einem konfigurierbaren Produkt. Wer ein CRM mit sehr spezifischen Prozessen braucht, wird früher oder später an diesen Punkt kommen.
Warum man beides zusammen betreiben will
In der Praxis sieht die Lage meist so aus: Der Vertrieb arbeitet im CRM. Die Dokumente – Angebote, Verträge, technische Unterlagen, Protokolle – liegen irgendwo anders. Häufig in Nextcloud, weil dort die Ablage strukturiert ist, die Rechteverwaltung stimmt und die Versionierung funktioniert. Das führt zu einem Zustand, den man freundlich als „gewachsene Landschaft“ bezeichnet und weniger freundlich als Datenchaos.
Konkret: Ein Vertriebsmitarbeiter legt den Angebotsentwurf als Anhang an die Verkaufschance in Insightly. Die technische Abteilung arbeitet parallel an derselben Datei in Nextcloud. Nach drei Iterationen gibt es zwei Wahrheiten. Später fragt jemand aus der Buchhaltung nach der finalen Fassung, und niemand kann sie sicher benennen. Das ist kein technisches Problem, es ist ein organisatorisches – aber es lässt sich technisch entschärfen.
Denn die eigentliche Frage lautet: Wo lebt ein Dokument, und wie kommt es von dort in den Kontext, in dem es gebraucht wird? Die Antwort sollte idealerweise lauten: Es lebt an genau einer Stelle, und überall sonst gibt es einen Verweis darauf. Nextcloud kann diese eine Stelle sein. Insightly kann der Kontext sein. Dazwischen braucht es eine Brücke.
Vier Wege, Nextcloud und Insightly zu verbinden
Der manuelle Weg. Freigabelink in Nextcloud erzeugen, Link in ein benutzerdefiniertes Feld am CRM-Datensatz eintragen, fertig. Kostet nichts außer Disziplin, funktioniert überraschend gut in kleinen Teams und ist erstaunlich fehlerträchtig, sobald die Zahl der Beteiligten steigt. Freigaben laufen ab, Ordner werden umbenannt, Berechtigungen ändern sich. Nach einem Jahr weiß niemand mehr, welcher Link wohin zeigt.
Der Low-Code-Weg. Eine Automatisierungsplattform wie Zapier, Make oder – wenn es datenschutzfreundlicher sein soll – ein selbst betriebenes n8n übernimmt die Vermittlung. Insightly sendet bei einer Statusänderung einen Webhook, die Plattform legt daraufhin in Nextcloud einen Ordner nach definiertem Muster an, erzeugt eine gruppenbasierte Freigabe und schreibt den Link zurück in den CRM-Datensatz. Das ist in wenigen Tagen gebaut und deckt einen großen Teil der Anforderungen ab.
Der eigene Middleware-Weg. Wenn die Anforderungen wachsen, kommt man um eigenen Code kaum herum. Ein kleiner Dienst, der über die Insightly-API Änderungen abholt oder Webhooks entgegennimmt, mit der Nextcloud-OCS-API Ordner und Freigaben erzeugt und die Ergebnisse zurückschreibt. Technisch ist das überschaubar. Der Aufwand liegt weniger im ersten Wurf als im Betrieb: Fehlerbehandlung, Wiederholungsversuche, Protokollierung, Token-Rotation.
Der eingebettete Weg. Mit der External-Sites-App lassen sich externe Webanwendungen in die Nextcloud-Oberfläche einbetten – in Grenzen, abhängig davon, ob die Gegenseite Iframes erlaubt. Umgekehrt kann man aus dem CRM heraus auf Nextcloud verweisen, etwa über eine tiefe Verlinkung auf einen bestimmten Ordner. Elegant, aber mit Einschränkungen: Single Sign-on über Systemgrenzen hinweg ist hier meist nicht sauber lösbar.
In der Praxis ist die Mischung üblich. Der Low-Code-Weg für die schnellen Fälle, die eigene Middleware für die kritischen, der manuelle Weg für alles, was selten vorkommt. Wichtig ist, dass es eine verbindliche Antwort auf die Frage gibt, wo ein Dokument liegt – sonst wandert die Unordnung nur von der Ablage in die Integration.
Ordnerstrukturen, die tragen
Wer die Integration baut, sollte vorher über die Struktur nachdenken. Eine Ordnerstruktur, die im CRM referenziert wird, muss stabil sein. Das heißt: Namen werden nicht nachträglich geändert, Projektordner werden nicht verschoben, und die Vergabe folgt einer Regel, die auch ein Skript versteht. Bewährt hat sich ein Schema nach Kunde und Vorgang, etwa ein Kundenordner mit einem Unterordner je Projekt, und darin die üblichen Unterteilungen nach Angebot, Vertrag und Dokumentation.
Nextcloud bietet hier mehr Bordmittel, als man auf den ersten Blick vermutet. Team-Ordner mit erweiterten Berechtigungen erlauben es, Rechte auf Ordnerebene granular zu setzen, auch gegen die Standardvererbung. Automatisiertes Tagging über Flow kann Dokumente nach Dateiendung, Namensmuster oder Inhalt verschlagworten. Die File-Access-Control-Regeln greifen auf diese Tags zu und können beispielsweise verhindern, dass eine als vertraulich markierte Datei überhaupt geteilt werden kann. Das ist im Zusammenspiel mit einem externen CRM besonders relevant, weil dort Links entstehen, die man später nur schwer zurückholt.
Ein weiterer Punkt ist die Löschlogik. Im CRM verschwindet ein Datensatz, wenn ein Vorgang abgeschlossen oder abgebrochen wurde. In der Ablage dürfen die dazugehörigen Dokumente deshalb noch lange nicht verschwinden – Aufbewahrungsfristen, Nachweispflichten, Revision. Wer hier keine Regel definiert, bekommt entweder einen unaufgeräumten Datenbestand oder gelöschte Unterlagen, die jemand später dringend braucht. Beides ist unschön, Letzteres deutlich unangenehmer.
Datenschutz, Auftragsverarbeitung und die Frage nach dem Speicherort
Die Kombination aus selbst betriebener Plattform und SaaS-CRM bringt eine Konstellation mit sich, die man sauber aufsetzen muss. Für Nextcloud als eigene Instanz ist man selbst der Verantwortliche; betreibt man sie bei einem Dienstleister, braucht es einen Auftragsverarbeitungsvertrag. Für Insightly als amerikanischen Anbieter kommt die Übermittlungsthematik hinzu. Seit dem EU-US Data Privacy Framework gibt es wieder eine Rechtsgrundlage für Übermittlungen an zertifizierte Anbieter, aber die Zertifizierung sollte man prüfen, und die eigene Risikoanalyse bleibt notwendig. Ein pauschales „passt schon“ ist hier fehl am Platz.
Praktisch bedeutet das vor allem Datenminimierung. Nicht jede Information, die im CRM nützlich sein könnte, gehört dorthin. Vertragsdokumente mit personenbezogenen Daten müssen nicht als Anhang im US-System liegen, wenn ein Link auf eine Nextcloud-Freigabe denselben Zweck erfüllt – und dabei die Kontrolle über die Datei bei der eigenen Instanz belässt. Das ist ein starkes Argument für die Integration, nicht nur ein technisches Detail.
Zu klären ist außerdem die Authentifizierung. Nutzer sollten möglichst nicht zwei getrennte Konten mit zwei verschiedenen Passwörtern pflegen. Idealerweise laufen beide Systeme auf dieselbe Identitätsquelle, sei es über SAML oder OIDC. Wo das nicht geht, helfen zumindest App-Passwörter für die Integration – nie das persönliche Konto eines Administrators, dessen Ausscheiden später ein Problem darstellt. Zugangsdaten gehören in einen Secrets-Store, nicht in eine Konfigurationsdatei im Repository.
Wenn Open Source konsequent sein soll
Es gibt Unternehmen, für die die Kombination mit einem US-SaaS-CRM nicht in Frage kommt. Für die ist die naheliegende Alternative ein Open-Source-CRM, das sich selbst betreiben lässt. EspoCRM ist schlank, schnell und funktional erstaunlich reif für den Vertriebsalltag. SuiteCRM ist mächtiger, aber schwerer zu pflegen und in der Bedienung weniger freundlich. Odoo deckt CRM und ERP ab und ist entsprechend umfangreich. Twenty ist ein jüngerer Kandidat, mit modernem Stack, aber noch nicht in jeder Hinsicht ausgereift. Und dann gibt es die ganz klassische Variante: ein schlankes, selbstgebautes CRM im Nextcloud-Ökosystem, für Teams, deren Vertriebsprozess überschaubar ist.
Der Preis für diese Konsequenz ist immer derselbe: Betriebsaufwand. Ein selbst betriebenes CRM braucht Updates, Backups, Monitoring, Sicherheitspatches, Schulung und jemanden, der sich um die Datenqualität kümmert. Das ist machbar, aber es ist Arbeit, und diese Arbeit verschwindet nicht dadurch, dass sie keine Lizenzkosten verursacht. Nextcloud ist kostenlos verfügbar, nicht kostenlos. Das gilt für jedes selbst betriebene System, und wer das Projekt ohne diese Einsicht startet, wird es früher oder später bereuen.
Kosten und Betriebsrealität
Zur Rechnung gehören mehr Posten, als in den meisten Business Cases auftauchen. Da ist die Hardware oder der Cloud-Anteil, die Speicherkapazität, der Backup-Speicher – und zwar an einem anderen Ort, bitte. Da sind die Personalkosten. Und da ist die Zeit, die in Upgrades fließt. Nextcloud veröffentlicht in einem Rhythmus von etwa vier bis sechs Monaten eine neue Hauptversion, jede mit einem Wartungsfenster. Der Sprung über mehrere Major-Versionen gleichzeitig ist nicht vorgesehen und bereitet regelmäßig Ärger. Wer eine Instanz ein Jahr liegen lässt, hat danach eine Migration vor sich, nicht ein Upgrade.
Auf der Habenseite steht eine Plattform, die sich an die eigenen Anforderungen anpassen lässt, deren Daten im eigenen Haus liegen und deren Kosten nicht mit jedem zusätzlichen Nutzer in die Höhe springen. Bei mehreren hundert Anwendern kann dieser Effekt erheblich sein – die Abonnements für Speicher, Office-Lizenzen und Zusammenarbeitswerkzeuge summieren sich in anderen Modellen schneller, als man denkt. Und nicht zuletzt entfällt die regelmäßige Diskussion darüber, ob man einen Preisaufschlag akzeptiert oder umzieht.
Ausblick
Die interessanten Entwicklungen liegen derzeit weniger in der Dateiverwaltung als daneben. Nextcloud arbeitet seit einiger Zeit an KI-Funktionen, die lokal betrieben werden können – Assistenten für Textzusammenfassung, Kontextsuche über Dokumente, Transkription. Das ist strategisch bemerkenswert, weil es die Souveränitätsdiskussion um eine Ebene erweitert. Wer seine Dokumente schon im eigenen Haus hält, will sie nicht für jede Zusammenfassung an einen fremden Dienst schicken.
Auf der CRM-Seite geht die Reise in eine ähnliche Richtung, dort allerdings meist mit anderer Konsequenz. Automatisierte Kontaktvorschläge, Umsatzprognosen, E-Mail-Zusammenfassungen – das existiert und wird mehr werden, aber in der Regel auf Grundlage der Daten beim Anbieter. Wer beides nutzen will, ohne alles an einer Stelle zu zentralisieren, braucht genau die Art von Integration, um die es hier geht: eine, die Daten dort belässt, wo sie hingehören, und nur die nötigen Ausschnitte austauscht.
Ein interessanter Aspekt dabei: Die technische Verbindung zwischen Nextcloud und Insightly ist vergleichsweise einfach. Die eigentliche Arbeit steckt in der Frage, welche Daten wohin gehören dürfen. Und diese Frage beantwortet kein Plugin, kein Webhook und keine API-Dokumentation. Sie beantwortet das Unternehmen selbst – idealerweise bevor die ersten Ordner angelegt sind. Alles andere rächt sich spätestens dann, wenn die Revision klingelt.