CaseFlow.
Schlanke Fallbearbeitung um Transparenz, Auditierbarkeit und Soft-Delete-only herum gebaut. Keine Per-Seat-Lizenz, läuft auf jedem Linux-Server.
Vorschau · Demo erscheint in Kürze
Die meisten Fallbearbeitungssysteme sind entweder überdimensioniert (Jira, ServiceNow — gute Produkte, aber du bezahlst für eine Organisation, die nicht deine ist) oder unterdimensioniert (ein geteilter Posteingang, eine Tabelle, ein Trello-Board — funktioniert, bis ein Prüfer nach der Historie fragt).
Das Mittelsegment — Betriebe, die Fälle, interne Anfragen oder regulatorische Vorgänge in Teams von 5–50 Personen handhaben — sitzt zwischen den beiden fest. Per-Seat-Preise werden unverhältnismäßig, Standardsysteme sind überbaut, und Eigenentwicklung wird aufgeschoben, bis jemand zeigt, dass es anders geht.
CaseFlow ist eine schlanke Vorgangsqueue, die eine Sache gut macht: Fall anlegen → zuweisen → kommentieren, anhängen, Status ändern → jede Veränderung für immer sehen. Keine Lizenzgebühren pro Nutzer. Kein Vendor Lock-in.
Was es kann
- Fälle — anlegen, zuweisen, kommentieren, Dateien anhängen, Status ändern (Neu → In Bearbeitung → Fertig → Geschlossen).
- Soft-Delete only — nichts wird wirklich gelöscht; alles ist innerhalb des Retention-Fensters wiederherstellbar.
- Audit-Trail auf allem — jeder Schreibvorgang unveränderlich mit Before/After-Diff geloggt, automatisch über einen EF-Core-SaveChanges-Interceptor erfasst.
- Idempotency auf Schreibvorgängen — jeder API-Aufruf verlangt einen Idempotency-Key-Header (Stripe-Modell).
- Fail-open KI-Unterstützung — Auto-Kategorisierung, Zusammenfassung, Antwortvorschläge via selbst-gehostetem LLM. Ist die KI aus, funktionieren Fälle trotzdem.
- Suche via SQLite FTS5 über Falltitel und Beschreibung. Die Demo-Umgebung wird jede Nacht um 03:00 Uhr auf den Seed-Baseline zurückgesetzt.
- Zwei Rollen — Admin (voller Systemzugriff) und User (eigene und zugewiesene Fälle).
- Benachrichtigungen — E-Mail und Push bei Zuweisung, Kommentar, Statusänderung.
Was es unterscheidet
Backend-first als Prinzip, nicht als Slogan. Sämtliche Audit-, Soft-Delete-, Idempotency- und Autorisierungslogik wird serverseitig durchgesetzt. Das Frontend ist ein dünner View-Layer. SQLite auf NFS ist eine Architekturentscheidung, kein Kompromiss — Single-Tenant-Nutzung im nächtlichen-Reset-Maßstab, k6-Stresstests im CI beweisen Korrektheit unter Nebenläufigkeit.
Es gibt kein hartes Löschen. Das Datenvolumen ist nicht das Problem; die Auditierbarkeit ist es.