Loki Time Master - Ein Service, der die Zeiterfassung für Teams in Notion ermöglicht

Die Situation

Derzeit sammeln wir Time Log Exporte aus Notion-Projektdatenbanken und führen sie für das Projektcontrolling und die Abrechnung zusammen. Dies ermöglicht es uns jedoch nicht, ein Gefühl für die Auslastung eines einzelnen Teammitglieds und die potenzielle Schwierigkeit bei der Bearbeitung mehrerer Projekte und anderer Aufgaben zu bekommen.

• Aufgabenerfassung in verschiedenen Notion-Datenbanken, jede für ein anderes Projekt
• Teammitgleider erfassen ihre Zeiten in Time Log Datenbanken für jedes Projekt
• Teammitglieder haben persönliche Excel-Dateien für die Zeiterfassung, um ein vollständiges Bild für sich selbst zu erhalten und eine zentrale Stelle für die Dateneingabe zu haben
• die Mitarbeiter übertragen dann regelmäßig ihre persönliche Zeiterfassung in die Boards der Projekte bzw. Projektdatenbanken um die Abrechnung zu ermöglichen.

Die Herausforderung

Dieses System funktionierte anfangs, aber als unser Team wuchs, zeigten sich Brüche, die zu den folgenden Herausforderungen führten

• Teammitglieder bestehen auf einem vollständigen Bild für sich selbst, einschließlich interner, nicht projektbezogener Zeit
• doppelter Aufwand bei der Zeiterfassung in persönlichen Dateien und beim Abgleich von Project Time Logs
• kein vollständiges Bild über den Auslastung für die Unternehmensleitung
• Notion-Automatisierungen scheinen Einschränkungen zu haben, wenn es um die Aktualisierung verknüpfter Elemente geht, und sind etwas anfällig für Benutzerfehler (Zeilen können SEHR leicht hinzugefügt und gelöscht werden)

Der Lösungsansatz

• jedes Teammitglied kann seine eigene persönliche Zeiterfassung haben
• die persönliche Time Log Datenbank ist verbunden mit Tickets aus verschiedenen Projektdatenbanken aber nur zu denen, bei denen das Teammitglied auch mitwirkt
• Persönliche Time Logs werden automatisch aggregiert, um ein vollständiges Bild über das gesamte Unternehmen zu erhalten und die Abrechnung und Reporting zu erleichtern

Aber Notion hat derzeit Einschränkungen

Da Notion derzeit über keine ausgefeilten Datenbank- und Programmierfunktionen verfügt, haben wir uns entscheiden, einen externen Dienst zu entwickeln, der die Notion-Daten verwaltet und synchronisiert. Wir hoffen, dass wir diesen Dienst in Zukunft loswerden können, wenn Notion Fortschritte macht.

Wir haben versucht, diesen separaten Dienst so schlank wie möglich zu halten, um den Wartungsaufwand gering zu halten.

Der externe Dienst, den wir entwickeln

Im Grunde genommen aggregieren wir Time Logs, speichern sie in einer Datenbank und stellen sie für die weitere Verarbeitung und Berichterstattung über Exporte in Excel oder unser Data Grid zur Verfügung.

Dafür brauchen wir mehr als nur Time Logs

• Kunden, Projekte und Benutzer synchronisieren: Notion → Loki
• Tasks aus Projekten synchronisieren: Notion → Loki
• Synchronisieren und Backups von Time Logs mit der optionalen Verbindung zu Tasks: Notion → Loki
• Verteilen von Projektbezogenen Tasks auf persönliche Task Datenbanken von Teammitgliedern, um die Verknüpfung von persönlichen Time Logs zu ermöglichen: Notion → Notion via Loki

... und all das kommt mit Einschränkungen in Notion

Die Notion-API erlaubt 3 Anfragen pro Sekunde und die Abfrage von maximal 100 Elementen pro Datenbankanfrage. Die Synchronisierung all dieser Einträge, die mit der Zeit immer mehr werden, muss sorgfältig gehandhabt werden und nimmt einige Zeit in Anspruch.

Lösungsentwurf

Jetzt haben wir also unsere Anforderungen. Die Benutzer sollten ihre persönliche Datenbank zur Zeiterfassung haben, die mit ihrer persönlichen Datenbank für Tasks verbunden ist, so dass das Task-Dropdown nur Tasks anzeigt, die für sie relevant sind. Und diese persönliche Task Datenbank muss mit Daten aus verschiedenen Projektdatenbanken gefüllt werden. Und diese Prozesse zur Synchronisierung müssen alle irgendwie konfiguriert werden. Dies führte uns zu dem Entwurf, bei dem wir die Konfiguration des Setups in einer weiteren Notion Datenbank speichern.

Als Ergebnis haben wir die folgenden Komponenten im System:

Datenbanken in Notion

• Master-Datenbanken
  ... diese sind die „Konfigurations-UI“ für Loki. Auf diese Weise müssen wir unserer Anwendung nur die IDs dieser Master-Datenbanken zur Verfügung stellen, und sie kann alle weiteren Konfigurationen abrufen, ohne dass wir eine eigene Benutzeroberfläche benötigen.
  • Master User Database
    ... Identifiers für Benutzer
    ... ID der persönlichen Aufgabendatenbank
    ... ID der persönlichen Task Datenbank
  • Master Customer Database
    ... alle Kundeninformationen an einem Ort
  • Master Project Database
    ... verknüpft mit der Kundendatenbank
    ... Liste der Teammitglieder
    ... ID der Aufgabe Datenbank des Projekts
  • Master Log Database
    ... Logs verschiedener Sync-Prozesse, um Einblicke in den aktuellen Status von Loki zu erhalten
• Project XXX Task Database
  ... projektspezifische Aufgabendatenbank, die im Projektmanagement verwendet wird, wo Projektteams die tägliche Arbeit verwalten
• Person XXX Task Database
  ... empfängt alle Tasks für den Benutzer aus allen Projektdatenbanken, in denen der Benutzer Mitglied ist
• Person XXX Time Log Database
  ... Zeitprotokolle des Benutzers, verknüpft mit der Tasks aus der Person XXX Task Database

innerhalb des externen Dienstes Loki

• zentrale SQL-Datenbank mit mehreren Tabellen zur Speicherung der synchronisierten Daten in einem konsistenten, verknüpften Datenmodell
• Endpunkte in einer Next.js-App für verschiedene Synchronisations-Workflows
  • Projektkonfiguration aktualisieren
  • Benutzerkonfiguration aktualisieren
  • Backup der Person XXX Time Log Database
  • Verteilung von Tasks aus der Project XXX Database in die Person XXX Database

Skalierung und Umgang mit möglichen Problemen

Theoretisch könnten viele dieser Prozesse die Notion-Automatisierungen vollständig nutzen, um aktualisierte oder erstellte Datensätze automatisch zu synchronisieren. Aber was passiert, wenn Loki selbst (oder unser Hosting-Anbieter Vercel) gerade nicht verfügbar ist? In diesen Fällen müssen wir sicherstellen, dass wir keine Aktualisierungen verpassen. Aus diesem Grund folgen alle unsere Synchronisierungsprozesse einem ähnlichen Muster:

1. Prüfen, wann der Sync das letzte Mal erfolgreich war
2. Abrufen aller Daten aus Notion, die sich nach der letzten Synchronisierung geändert haben
3. Neue Daten in das Zielsystem in der Reihenfolge ihrer Update Zeit schreiben.

Auf diese Weise kann man, egal wo ein Prozess zwischen diesen Schritten fehlschlägt, den Prozess einfach erneut starten, um alle Daten wiederherzustellen.

Workflows in einer serverlosen Welt

Um schneller startklar zu sein, ist Loki eine Next.js-App, die auf Vercel gehostet wird. Auf diese Weise haben wir im Grunde keinen Aufwand für Wartungs- oder Bereitstellungsarbeiten. Allerdings ist Vercel ein serverloser Dienst. Man kann nicht wissen, ob man 1 Instanz hat, die gerade läuft, oder 100. Das ist aber eigentlich ein Nachteil für uns:

1. Unsere Jobs sind durch das Ratenlimit der Notion-API begrenzt. Die parallele Ausführung von zwei separaten Prozessen verlangsamt jeden von ihnen.
2. Die Tatsache, dass wir dieselben Daten zweimal von Notion erhalten, weil derselbe Auftrag parallel läuft, verlangsamt uns aufgrund des API-Ratenlimits noch weiter.

Das heißt, wir müssen sicherstellen, dass immer nur eine Instanz eines Synchronisierungsauftrags ausgeführt wird. Wir können dies sehr einfach erreichen, indem wir die Datenbank als Sperrmechanismus verwenden. Wenn ein Auftrag ausgelöst wird, wird zunächst geprüft, ob der Auftrag bereits läuft, und wenn ja, wird ein Objekt in eine Warteschlange gestellt (eine Datenbanktabelle mit wartenden Aufträgen). Immer wenn ein Auftrag beendet ist, wird die Warteschlange auf ausstehende Aufträge überprüft und diese ausgelöst.

Und schließlich hat Vercel ein Limit für die Dauer der Anfrage. Um dies zu beheben, können wir unsere Aufträge in kleinere Teile zerlegen und jeden Teil mit einer neuen Abrufanfrage an den Server selbst auslösen. Auf diese Weise haben wir zwar mehr Anfragen, aber jede einzelne bleibt deutlich unter dem Zeitlimit.

Was denkt ihr?

So, das war eine kurze Zusammenfassung unserer Gedanken und unseres Ansatzes, aber wir würden gerne deine Meinung zu dieser Lösung hören!

• Was übersehen wir?
• Liegen wir in bestimmten Punkten falsch?
• Wie können wir mehr daraus machen?
• Könnte es noch tiefer in die aktuellen Möglichkeiten von Notion integriert werden?

Schreib mir :) robert.kramer@esveo.com