Zum Inhalt springen

Änderungshistorie

Jede Änderung an einer Entität wird protokolliert: wer, wann, welche Aktion — und bei Änderungen auch die betroffenen Feldwerte. Du siehst die Historie an zwei Stellen:

  • Detailansicht einer Entität — der Abschnitt „Historie” zeigt die Änderungen genau dieser Entität.
  • Seite „Audit Logs” in der Sidebar — alle Änderungen deines Mandanten über alle Module hinweg.

In der Detailansicht stehen höchstens fünf Einträge, die neuesten zuerst. Das ist Absicht: eine viel bearbeitete Entität bringt hunderte Einträge mit, und ungekappt schöben sie alles darunter — Freigaben, Abwesenheiten, Auswertungen — aus dem Blickfeld.

Gekappte Änderungshistorie mit dem Knopf „Alle anzeigen"

Gibt es mehr, steht darunter „Alle anzeigen” mit der Gesamtzahl. Der Knopf öffnet ein Fenster mit der vollständigen Historie; beim Scrollen lädt sie weiter nach. Dort führt auch ein Link „Auf der Audit-Seite öffnen”.

Fenster mit der vollständigen Historie

Die Seite „Audit Logs” zeigt dann nur die Einträge dieser einen Entität, erkennbar am Filter-Merkmal oben. Über das × daneben kommst du zurück zur vollständigen Liste des Mandanten.

Bei Zeichnungen ist die Historie ein eigener Reiter mit mehr Platz — dort stehen fünfzehn Einträge, der Rest ebenso im Fenster.

Die Historie folgt derselben Sichtbarkeit wie die Entität selbst. Das ist die entscheidende Regel: ein Historien-Eintrag zu einer Änderung trägt die Feldwerte der Entität — wer die Entität nicht sehen darf, darf auch ihre Historie nicht lesen.

Konkret:

  • Ist dir eine Entität verborgen, siehst du weder ihre Einträge in der Liste noch deren Details.
  • Bei einer Beziehung musst du beide verbundenen Entitäten sehen dürfen. Sonst verriete der Eintrag, dass die verborgene Entität existiert und woran sie hängt.
  • Einträge ohne Entitätsbezug — Anmeldungen, Regeländerungen im Automator oder Validator, Aufräumläufe — bleiben für alle im Mandanten sichtbar.
  • Mandantengrenze: Einträge anderer Mandanten sind nie sichtbar, auch nicht mit bekannter Ereignis-ID. Nur Platform-Admins arbeiten mandantenübergreifend.

Jeder Eintrag nennt Objekt, handelnde Person und Zeitpunkt. Seit September 2026 stehen darin bei allen drei Vorgängen auch die Feldwerte: beim Anlegen der erzeugte Datensatz, bei einer Änderung der neue Stand, beim Löschen der Stand unmittelbar davor.

Vorher trug nur die Änderung Inhalte. Das hatte eine Folge, die erst auffiel, als die Zeitreise darauf aufsetzte: ein Objekt, das angelegt und wieder gelöscht wurde, ohne dazwischen bearbeitet worden zu sein, hinterließ nirgends seinen Namen. Es war danach eine bloße Kennnummer — im Verlauf wie in der Zeitreise.

Auch Vorgänge, die früher gar nichts hinterließen, stehen jetzt im Verlauf: eine Massenfreigabe (sie meldete nur, wie viele Objekte betroffen waren), eine Schema-Migration (sie schreibt Felder aller Objekte eines Mandanten um) und das Zurücksetzen auf einen Versionsstand. Damit die Oberfläche davon nicht überflutet wird, erscheinen die Einzeleinträge eines solchen Sammelvorgangs zwar im Verlauf, lösen aber keine Einzelmeldungen aus.

Bei einer Verknüpfung stehen im Eintrag beide verbundenen Objekte, die Art der Verknüpfung, ihre Merkmale und etwaige weitere Beteiligte. Das ist neu: bis September 2026 trugen die Merkmale nur die Einträge eines einzigen Löschwegs, und die weiteren Beteiligten standen nirgends. Eine gelöschte Verknüpfung kam damit — wenn überhaupt — als nackte Zweierbeziehung zurück.

Ebenfalls neu: Verknüpfungen, die mit einem gelöschten Objekt zusammen entfallen, werden vollständig aufgeschrieben. Vorher endete die Liste bei fünfhundert; bei einem stark verbundenen Objekt fehlte der Rest. Statt zu kürzen schreibt die Anwendung jetzt mehrere Einträge.

Zwei Fälle überraschen erfahrungsgemäß:

  • Gelöschte Entitäten. Ist eine Entität gelöscht, lässt sich nicht mehr feststellen, ob du sie hättest sehen dürfen. Ihre Historie ist deshalb für dich nicht mehr sichtbar. Tenant-Admins und Security Officer sehen sie weiterhin — für sie gilt die Sichtbarkeitsprüfung ohnehin nicht.
  • Ältere Beziehungs-Einträge, denen die Angaben zu den verbundenen Entitäten fehlen. Wenn nicht entschieden werden kann, ob du sie sehen darfst, wird der Eintrag ausgeblendet statt angezeigt.

Wenn du einen Eintrag brauchst, den du nicht siehst, wende dich an deinen Tenant-Admin — er kann dir entweder die Sichtbarkeit auf die Entität geben oder den Eintrag selbst nachsehen.

Die Zeitreise im Graphen — was sie zeigt und was nicht

Abschnitt betitelt „Die Zeitreise im Graphen — was sie zeigt und was nicht“

Der Datums-Schieber in der Graph-Ansicht spielt den Stand zum gewählten Tag zurück: Entitäten und Verknüpfungen, die es an diesem Tag noch nicht gab, verschwinden; was an dem Tag entstand oder gelöscht wurde, ist hervorgehoben. Grundlage sind dieselben Aktivitätsprotokolle wie hier — mit zwei Folgen:

Auch was es heute nicht mehr gibt, ist wieder da. Seit September 2026 zeigt die Zeitreise nicht nur, was vom heutigen Bestand am Stichtag schon existierte — sie holt gelöschte Objekte aus dem Aktivitätsprotokoll zurück, mit ihrem Typ, ihrer Farbe und ihrem Namen. Vorher zeigte „so sah es am 14. Mai aus” alles außer dem, was seither verschwunden ist, und sagte das nicht.

Drei Grenzen bleiben — und die Ansicht benennt sie, statt sie zu verschweigen:

  • Nur so weit zurück, wie Protokolle vorliegen. Der Schieber beginnt beim ältesten bekannten Ereignis. Was vor der Aufbewahrungsfrist entstand, hat keinen Entstehungs-Eintrag mehr und wird deshalb immer angezeigt — auch an einem Datum davor. Das ist Absicht: eine unvollständig leere Ansicht wäre irreführender als eine vollständige.
  • Nicht jedes gelöschte Objekt hat noch einen Namen. Wer vor September 2026 angelegt und nie bearbeitet wurde, hinterließ keinen. Solche Objekte erscheinen ohne Namen, und die Zeitleiste sagt, wie viele es waren.
  • Gelöschte Objekte sieht nur, wer ohnehin alles sieht. Mit dem Objekt sind auch seine Freigaben gelöscht worden; ob du es hättest sehen dürfen, lässt sich nicht mehr feststellen. „Unbekannt” darf nicht „frei” heißen — deshalb bleiben sie für Nutzer mit eingeschränkter Sicht draußen, und die Zeitleiste sagt auch das.

Der Stand eines Tages wird beim Anklicken geladen — er fragt die Data Nodes nach den Namen. Solange das läuft, steht das bisherige Bild abgeblendet still, und in der Zeitleiste steht „Stand wird geladen”.

Was die Zeitreise nicht zeigt: wie ein Feld eines noch existierenden Objekts damals formuliert war. Sie stellt den Bestand her, nicht jede Fassung jedes Textes.

Der Zeitstrahl wirkt in allen drei Ansichten der Graph-Seite — auch im Explorer, der von einem Ausgangspunkt aus erkundet. Dort folgt dem Stichtag nicht nur, welche Karten zu sehen sind, sondern auch die „+N”-Marke an einem Knoten und die Zeilen auf den Karten: beide sprechen über den gewählten Tag, nicht über heute.

Zwei Dinge, die dabei auffallen können:

  • Ein Ausgangspunkt, den es am gewählten Tag noch nicht gab, fällt weg. Die übrigen tragen das Bild weiter, und eine Zeile über der Fläche sagt, wie viele es betraf. Der Ausgangspunkt ist nicht verloren — „Zurück auf heute” bringt ihn zurück. Gab es keinen einzigen von ihnen an dem Tag, sagt die Fläche das, statt leer zu bleiben.
  • Bearbeiten und Zeitreise schließen einander aus. Wer den Bearbeiten-Modus einschaltet, landet wieder auf dem heutigen Stand. In einen vergangenen Stand hineinzuzeichnen ist nicht gemeint — die Änderung würde ja doch in der Gegenwart landen.

Am wiederhergestellten Knoten einer Zeitreise steht im Rechtsklick-Menü „Auf diesen Stand zurückholen”. Das ist der einzige Ort dafür — eine Detailseite hat ein gelöschtes Objekt nicht mehr.

Es entsteht ein Vorschlag, keine sofortige Änderung. Das Zurückholen landet als Entwurf in der Entwurfsliste — wie jede andere Änderung, mit deinem Namen und dem Vermerk, auf welchen Stand es zurückgeht. Erst die Freigabe bringt das Objekt zurück. Der Toast bietet dir den Sprung in den Entwurf an.

Das ist Absicht: in einem Mandanten mit Konsens- oder Konsent-Freigabe soll ein gelöschtes Objekt nicht an genau den Personen vorbei wieder auftauchen, deren Zustimmung seine Löschung gebraucht hätte. Wird der Vorschlag abgelehnt, bleibt alles, wie es ist.

Was dabei passiert:

  • Das Objekt entsteht neu, mit seiner ursprünglichen Kennung. Verweise darauf greifen damit wieder.
  • Zurücknehmen ist immer vorwärts. Es wird nichts überschrieben und nichts aus der Historie entfernt; die Freigabe des Zurückholens steht als eigener Eintrag im Verlauf, mit deinem Namen. Auch aus einem Zurückholen führt der Weg wieder heraus — der Stand von davor steht im Verlauf und ist auf demselben Weg erreichbar.
  • Beziehungen kommen nicht ungefragt mit — sie sind ein eigener Menüpunkt.

Neben „Auf diesen Stand zurückholen” steht am wiederbelebten Knoten ein zweiter Punkt: „… mit seinen Verbindungen (N)”. Die Zahl sagt schon vorher, um wie viele es geht. Beides zusammen wird als ein Bündel eingebracht und gemeinsam freigegeben — sonst bekämst du das Objekt zurück und seine Einbettung in die Organisation nicht.

Eine einzelne Verbindung holst du über den Rechtsklick auf die Linie selbst zurück: „Diese Verbindung zurückholen”. Auch das gab es vorher nicht — eine Verknüpfung, die gelöscht wurde, während beide Enden stehenblieben, war nirgends wiederherstellbar.

Eine zurückgeholte Verbindung behält ihre ursprüngliche Kennung, ihre Merkmale und ihre weiteren Beteiligten. Damit hat dieselbe Verbindung einen durchgehenden Verlauf statt zweier unter zwei Nummern.

Was nicht mitkommt: eine Verbindung, deren Gegenstelle es heute nicht mehr gibt und die nicht im selben Bündel zurückkommt. Sie wäre eine Behauptung über etwas, das es nicht gibt. Wie viele das betraf, steht in der Rückmeldung — es wird nicht verschwiegen.

Ein gelöschtes Objekt zurückholen darf nur die Mandanten-Verwaltung: mit dem Objekt sind auch seine Freigaben gelöscht worden, und ob jemand anderes es hätte sehen dürfen, lässt sich nicht mehr feststellen. Liegt für das gewählte Datum kein Stand mehr vor, sagt die Anwendung das ausdrücklich — das ist etwas anderes als ein Fehler.