Fallstudie 03 / 05 · spfx · Version 1 live seit September 2026
Ein CRM, das in SharePoint lebt: Leads, Kontakte und Wiedervorlagen in Microsoft 365
Ein CRM für eine kleine Beratung, gebaut als SharePoint-Framework-Webpart: Leads, Firmen, Kontakte, Aufgaben und Berichte liegen in SharePoint-Listen, und die ganze App ist eine nummerierte Datei, die ein kleiner Loader aus einer Bibliothek holt. Produktentwurf, Ansichten und Geschäftsregeln stammen aus dem HTML-Prototyp der Führungskraft; ich habe den Lösungsweg entschieden, die SharePoint-Schicht, den Loader und die Einrichtungsskripte gebaut und das CRM ausgeliefert. Version 1 ist seit September 2026 live; Version 2 ist gebaut und paketiert.
Das CRM begann als HTML-Prototyp der Führungskraft in einer einzigen Datei: Leads, Kontakte und Wiedervorlagen auf einer Seite, die Daten im lokalen Speicher eines einzelnen Browsers. Einen gemeinsamen Datenspeicher gab es nicht, und eine Sicherung bedeutete manuellen Export.
Es gab keinen zulässigen Weg, ihn im Microsoft 365 des Unternehmens zu betreiben. SharePoint schaltet benutzerdefinierte Skripte innerhalb von 24 Stunden wieder ab, das Unternehmen hat keine Premium-Lizenz für Power Apps, und eine Canvas-App konnte das freigegebene Design nicht abbilden. Der unterstützte Weg ist ein SharePoint-Framework-Webpart; ich habe die Optionen verglichen und mich dafür entschieden.
Anfragen kommen als E-Mails und als Projektanzeigen von Personalagenturen, und sie neu abzutippen dauert; deshalb liest die App eine eingefügte E-Mail und schlägt Firma, Kontakt und Lead vor. Das Nachfassen hing früher am Gedächtnis; jetzt wird ein Lead ohne offenen nächsten Schritt markiert.
Gebaut für eine Person im Tagesgeschäft: die Inhaberin oder den Inhaber der Beratung. Die App unterscheidet keine Rollen. Die Führungskraft gibt jedes Release frei; nur sie lädt es hoch.
Nichts über Microsoft 365 hinaus: kein Server, keine zusätzliche Lizenz, und nichts verlässt den Tenant.
eine pro Firma
eine pro Person
eine pro Anfrage
eine pro Aktivität
eine pro Aufgabe
eine pro Datei oder Link
eine pro Quartalsabschluss
Vereinfacht: Sieben Kästen stehen für acht der 17 SharePoint-Objekte (Dateien und Links vereinen eine Bibliothek und eine Liste). Nicht gezeichnet: Veranstaltungen, Marktbeobachtung und Tagessatz-Vergleichswerte (gleiches Muster), die OKR-Liste, vier angelegte Listen, die keine Ansicht nutzt, und die App-Bibliothek (Code, keine Daten). Das ist Version 2; Version 1 hatte 14 Listen. Gestrichelter Rahmen: Dokumentbibliothek oder Dateiablage.
Jeder Datensatz hat einen eigenen App-Schlüssel. So bleiben die SharePoint-IDs intern, und Verknüpfungen überstehen Umbenennungen. Verlauf, Aufgaben, Dateien und Links zeigen über Art und App-Schlüssel auf jeden beliebigen Datensatz.
Technische Namen ändern sich nie; deutsche Anzeigenamen liegen darüber, sodass sich Listen und Spalten umbenennen lassen, ohne die App zu stören.
Die Trefferquote ist der Anteil gewonnener Leads an allen gewonnenen und verlorenen Leads des Zeitraums; zurückgezogene Leads bleiben außen vor. Beim Abschluss eines Quartals werden die Zahlen in einer Zeile der Quartalsergebnisse eingefroren.
Nur ein Loader-Webpart von 17 KB läuft über den App-Katalog des Tenants und wird einmalig von der Administration installiert. Das CRM selbst ist eine nummerierte Datei in einer Bibliothek der Site: Hochladen ist das Release, Löschen der Rollback, und Schemaänderungen fügen immer nur hinzu. Abwägung: Die Schreibrechte auf diese Bibliothek müssen streng eingeschränkt werden.
Listen mit festen technischen Namen, deutschen Anzeigenamen darüber und einem von der App erzeugten Schlüssel pro Datensatz: kein externes Hosting, kein Server, keine zusätzliche Lizenz. Abwägung: Die App muss die Integrität selbst sichern, sie geht von einer schreibenden Person zur Zeit aus, und der letzte Schreibvorgang gewinnt.
Jede Änderung landet zuerst im Store im Arbeitsspeicher, und der Bildschirm zeichnet sofort neu; ein Persister vergleicht dann Vorher und Nachher und sendet nur die geänderten Spalten, der Reihe nach im Hintergrund. Abwägung: Ein fehlgeschlagenes Speichern fällt erst spät auf, als Meldung und mit dem Zurücksetzen dieses einen Datensatzes.
Kein Framework, ein Shadow DOM und Übersetzung per Wörterbuch: So erscheint das freigegebene Design exakt, und spätere Überarbeitungen des Prototyps lassen sich weiter einspielen. Abwägung: Der größte Teil des Codes ist der übernommene Prototyp und nicht typgeprüft.
Version 1 ist seit dem 29. September 2026 live, 13 Tage nach dem ersten Commit am 16. September. Version 2 wurde am 14. Oktober gebaut und am 15. Oktober 2026 paketiert; sie wartet auf die Freigabe durch die Führungskraft. Die Live-Demo läuft mit dem Code von Version 2 und erfundenen Daten der fiktiven Nordstern Projektmanagement GmbH, gespeichert im Browser statt in SharePoint.
Live-Demo öffnen