Fehlende Datensätze in Automationen gezielt finden

Ein Auftrag fehlt im CRM, obwohl der Lauf der Automation erfolgreich wirkt. Für die Analyse ist nicht entscheidend, wie der Workflow grundsätzlich aufgebaut ist, sondern was mit genau diesem Auftrag passiert ist.

Lege dafür eine durchgehende Spur an: vom ursprünglichen Datensatz bis zum erwarteten Ergebnis. An jeder Übergabestelle prüfst du, ob dieser Fall angekommen ist, welche Werte vorlagen und welche Entscheidung die Automation getroffen hat.

Beginne mit dem fehlenden Datensatz, nicht mit dem Workflow

Ein typischer Supportfall lautet: „Die Anfrage von gestern ist nicht im CRM.“ Damit lässt sich noch wenig prüfen. „Die Anfrage mit der Formular-ID 18427 wurde am 14. Mai um 10:36 Uhr abgeschickt und hätte als neuer Kontakt im CRM erscheinen sollen“ ist dagegen eine belastbare Ausgangslage.

Halte vor der technischen Prüfung vier Angaben fest:

die eindeutige Kennung des Quelldatensatzes,
den Zeitpunkt einschließlich Zeitzone,
das erwartete Zielsystem und Objekt,
das erwartete Ergebnis, etwa „neuen Kontakt anlegen“ oder „bestehenden Auftrag aktualisieren“.

Fehlt eine eindeutige Kennung, helfen ersatzweise mehrere stabile Merkmale wie E-Mail-Adresse, Bestellnummer und Zeitstempel. Ein Name allein ist eine eher optimistische Form der Datenbankabfrage.

Wichtig ist auch die genaue Erwartung. Ein Kontakt kann im Zielsystem vorhanden sein und trotzdem als fehlend gelten, weil er einer anderen Firma zugeordnet, archiviert oder durch eine gespeicherte Ansicht ausgeblendet wurde. Ohne definiertes Soll suchst du möglicherweise nach einem technischen Fehler, obwohl das Ergebnis lediglich anders dargestellt wird.

Prüfe die Übergaben in ihrer tatsächlichen Reihenfolge

Verfolge den Datensatz nun vom Ursprung bis zum Ziel. Springe nicht direkt zur auffälligsten Stelle. Sonst prüfst du ausführlich eine CRM-Aktion, obwohl der Trigger den Fall nie erhalten hat.

Existiert der Quelldatensatz vollständig?

Öffne zuerst das System, in dem der Vorgang entstanden ist. Prüfe, ob der Datensatz gespeichert wurde und alle für die Automation relevanten Felder enthält. Bei Formularen kann beispielsweise eine Bestätigungsseite sichtbar gewesen sein, obwohl die serverseitige Speicherung scheiterte. Bei manuellen Eingaben kann ein Status fehlen, der den Prozess erst freigibt.

Notiere die Originalwerte möglichst unverändert. Besonders relevant sind Statusfelder, Auswahlwerte, Datumsangaben, E-Mail-Adressen und leere Pflichtfelder. Kopiere nicht nur das, was später im Zielsystem stehen soll. Für die Diagnose zählt, was die Automation tatsächlich erhalten konnte.

Hat der Trigger genau diesen Fall aufgenommen?

Suche im Ausführungsverlauf nach der Quellkennung oder dem Zeitfenster. Wird der Datensatz dort nicht angezeigt, liegt der Fehler vor dem eigentlichen Verarbeitungsweg. Mögliche Ursachen sind ein nicht ausgelöstes Ereignis, ein unterbrochener Webhook oder eine zeitgesteuerte Abfrage, die den Datensatz nicht erfasst hat.

Bei zeitgesteuerten Abfragen solltest du die Grenzen des abgefragten Zeitraums kontrollieren. Unterschiedliche Zeitzonen, verspätet gespeicherte Datensätze oder eine Abfrage mit „größer als“ statt „größer oder gleich“ können einzelne Fälle auslassen. Ändere die Zeitlogik jedoch erst, nachdem du den konkreten Zeitstempel mit der verwendeten Abfrage verglichen hast.

Welche Bedingung hat über den weiteren Weg entschieden?

Ist der Datensatz im Lauf vorhanden, prüfst du jeden Filter und jede Verzweigung. Entscheidend ist nicht, wie die Bedingung im Editor aussieht, sondern welche Werte zum Ausführungszeitpunkt verglichen wurden.

Häufige Abweichungen sind:

ein Statuswert mit anderer Schreibweise oder zusätzlichem Leerzeichen,
eine leere Zeichenkette anstelle eines technisch nicht vorhandenen Werts,
eine Zahl, die als Text übergeben wird,
ein Datum in einer anderen Zeitzone oder einem anderen Format,
eine Bedingung, die alle statt mindestens eines der Kriterien verlangt.

Dokumentiere für jede Verzweigung den Eingangswert, den Vergleichswert und das Ergebnis. „Filter sah korrekt aus“ ist kein Befund. „Status war Freigegeben mit nachgestelltem Leerzeichen, erwartet wurde Freigegeben“ ist einer.

Bleibt die Identität beim Umwandeln erhalten?

Zwischen Quelle und Ziel werden Daten oft zusammengeführt, bereinigt oder in ein anderes Format gebracht. Dabei kann die ursprüngliche Kennung verloren gehen. Danach lässt sich zwar noch ein Kontakt anlegen, aber nicht mehr eindeutig feststellen, zu welchem Ausgangsdatensatz er gehört.

Führe eine Quell-ID deshalb möglichst durch den gesamten Ablauf und speichere sie, sofern fachlich sinnvoll, auch im Zielsystem. Sie dient als Korrelations-ID: eine gemeinsame Kennung, mit der du denselben Vorgang über mehrere Systeme hinweg wiederfindest.

Prüfe außerdem die Zuordnung der Felder. Eine falsch zugeordnete E-Mail-Adresse kann dazu führen, dass die Suche nach einem bestehenden Kontakt kein Ergebnis liefert. Umgekehrt kann eine zu allgemeine Suche einen neuen Vorgang an einen alten Kontakt hängen. Der Datensatz fehlt dann nur an der erwarteten Stelle.

Was hat der Schreibvorgang tatsächlich zurückgegeben?

Eine ausgeführte Aktion belegt zunächst nur, dass der Schritt aufgerufen wurde. Prüfe, sofern das verwendete System diese Informationen bereitstellt, die Antwort des Zielsystems. Relevant sind die Ziel-ID, der ausgeführte Aktionstyp und mögliche Warnungen.

Achte besonders auf Schritte, die je nach Suchergebnis entweder anlegen oder aktualisieren. Dieses Verfahren wird häufig als Upsert bezeichnet. Findet die vorgeschaltete Suche einen vermeintlich passenden Eintrag, aktualisiert die Automation diesen, statt einen neuen anzulegen. Der Lauf bleibt technisch erfolgreich, während der erwartete neue Datensatz ausbleibt.

Suche im Zielsystem deshalb nicht nur nach dem Namen. Nutze die Quell-ID, E-Mail-Adresse, externe Referenz oder die vom Schreibvorgang zurückgegebene Ziel-ID. Kontrolliere auch Archive, Statusfilter, Zuständigkeiten und gespeicherte Ansichten.

Nutze eine einfache Entscheidungskette

Nach den Prüfungen lässt sich der Fehler meist einer klaren Übergabe zuordnen:

Kein Quelldatensatz: Der Fehler entstand vor der Automation, etwa bei Eingabe oder Speicherung.
Quelle vorhanden, aber kein Trigger-Lauf: Prüfe Ereignis, Webhook oder Abfragezeitraum.
Trigger-Lauf vorhanden, weiterer Schritt übersprungen: Prüfe Filterwerte und Verzweigungen.
Schritt ausgeführt, aber keine Ziel-ID: Prüfe Anfrage, Antwort und Feldzuordnung.
Ziel-ID vorhanden, Datensatz scheinbar nicht auffindbar: Prüfe Aktualisierungen, Dublettensuche, Archive, Rechte und Ansichtsfilter.

Diese Kette verhindert, dass mehrere mögliche Ursachen gleichzeitig bearbeitet werden. Ändere zunächst nur die Stelle, an der die Spur des konkreten Datensatzes endet. Sonst erzeugst du einen neuen Ablauf und weißt anschließend lediglich, dass nun etwas anders ist.

Wiederhole den Fall, ohne Folgeaktionen doppelt auszulösen

Ein fehlgeschlagener Datensatz sollte nicht unkontrolliert durch den gesamten Prozess geschickt werden. Die Automation könnte beim zweiten Versuch E-Mails erneut senden, Aufgaben doppelt anlegen oder einen bereits vorhandenen Eintrag noch einmal erzeugen.

Teile die Schritte vor einer Wiederholung gedanklich in lesende und schreibende Aktionen. Lesende Aktionen suchen oder laden Daten. Schreibende Aktionen verändern Systeme oder lösen Kommunikation aus. Deaktiviere beim Test alle Schreibaktionen, die für die Diagnose nicht erforderlich sind, oder leite sie in eine Testumgebung um.

Für den kontrollierten Test gehst du so vor:

Sichere die ursprünglichen Eingangsdaten des betroffenen Falls.
Notiere, welche Zielobjekte bereits entstanden sein könnten.
Deaktiviere Benachrichtigungen und andere irreversible Folgeaktionen.
Führe den Fall mit derselben Quell-ID erneut aus.
Prüfe nach jedem Übergang Ein- und Ausgabe.
Aktiviere den vollständigen Ablauf erst nach einem erfolgreichen Test.

Wenn Wiederholungen regelmäßig vorkommen können, sollte die Automation denselben Vorgang erkennen und sicher behandeln. Wie du dafür eindeutige Schlüssel einsetzt, zeigt der Artikel über das Verhindern doppelter Verarbeitung in Automationen.

Baue eine prüfbare Spur für künftige Supportfälle

Ein Ausführungsverlauf ist nur hilfreich, wenn du einen Geschäftsvorgang darin wiederfindest. Speichere daher an den wichtigen Übergaben wenige, aber eindeutige Angaben:

Quell-ID und gegebenenfalls Ziel-ID,
Zeitpunkt des Schritts,
Name oder Kennung des Verarbeitungsschritts,
Ergebnis einer Verzweigung,
Status des Schreibvorgangs,
eine verständliche Fehlerkennung.

Protokolliere keine Zugangsdaten und nicht vorsorglich sämtliche personenbezogenen Inhalte. Für die Fehleranalyse reicht häufig eine Kennung mit technischen Metadaten. Lege außerdem fest, wie lange solche Protokolle benötigt werden und wer darauf zugreifen darf.

Bei wichtigen Abläufen genügt es nicht, nur technische Fehler zu erfassen. Ergänze eine fachliche Abschlussprüfung. Nach dem Anlegen eines Kontakts kann der Prozess beispielsweise kontrollieren, ob eine Ziel-ID zurückgegeben und zusammen mit der Quell-ID gespeichert wurde. Fehlt sie, landet der Fall in einer Fehlerliste, statt still als abgeschlossen zu gelten.

Wenn du den Prozess erst planst, hilft die Checkliste vor der Automatisierung dabei, Ausnahmen, Zuständigkeiten und überprüfbare Ergebnisse früh festzulegen.

Wann ein eigenes internes Tool die Analyse erleichtert

Viele Automationsplattformen reichen für überschaubare Abläufe aus. Problematisch wird es, wenn Ausführungsdaten nur kurz verfügbar sind, mehrere Systeme beteiligt sind oder Mitarbeitende ohne Zugriff auf die technische Plattform Fehlerfälle klären müssen.

Dann kann eine kleine interne Oberfläche sinnvoll sein. Sie muss den Prozess nicht vollständig ersetzen. Oft genügt eine Suche nach Quell-ID, die den aktuellen Status, die durchlaufenen Stationen, das Zielobjekt und eine kontrollierte Wiederholung anzeigt. Das verkürzt die Fehlersuche, weil Support und Fachabteilung denselben Vorgang betrachten.

Ob eine solche Oberfläche angemessen ist, hängt von Häufigkeit, Auswirkung und Supportaufwand ab. Eine seltene Ausnahme rechtfertigt noch keine eigene Anwendung. Wenn fehlende Datensätze regelmäßig mehrere Personen beschäftigen, kann ein internes Tool für nachvollziehbare Arbeitsabläufe die fehlende Transparenz gezielt ergänzen.

Fazit: Die Lücke liegt zwischen zwei nachweisbaren Zuständen

Fehlende Datensätze findest du am zuverlässigsten, indem du einen konkreten Fall mit eindeutiger Kennung vom Ursprung bis zum Ziel verfolgst. Prüfe an jeder Übergabe den Eingang, die Entscheidung und das Ergebnis. Die erste Stelle ohne passenden Nachweis ist dein sinnvollster Ansatzpunkt.

Erst danach änderst du Filter, Feldzuordnungen oder Schreibaktionen. So reparierst du die tatsächliche Ursache, statt den Workflow auf Verdacht umzubauen. Die dokumentierte Spur beschleunigt außerdem die Prüfung künftiger Supportfälle.

Warum meldet eine Automation Erfolg, obwohl ein Datensatz fehlt?

Der Lauf kann technisch ohne Fehler enden, obwohl ein Filter den Fall übersprungen, eine Suche einen falschen Treffer geliefert oder eine Aktion einen vorhandenen Datensatz aktualisiert hat. Prüfe deshalb das fachliche Ergebnis und nicht nur den Laufstatus.

Wo sollte ich bei einem fehlenden Datensatz mit der Suche beginnen?

Beginne beim Quelldatensatz. Sichere seine eindeutige Kennung, den Zeitpunkt und das erwartete Ergebnis. Verfolge ihn danach in der tatsächlichen Reihenfolge durch Trigger, Bedingungen, Umwandlungen und Schreibaktionen.

Kann ich einen fehlgeschlagenen Fall einfach erneut ausführen?

Nur kontrolliert. Prüfe vorher, welche Aktionen bereits ausgeführt wurden, und deaktiviere E-Mails, Zahlungen oder andere irreversible Schritte. Verwende dieselbe eindeutige Quell-ID, damit keine Dubletten entstehen.

Welche Angaben sollte eine Automation für die Fehleranalyse protokollieren?

Hilfreich sind Quell-ID, Ziel-ID, Zeitstempel, Verarbeitungsschritt, Ergebnis von Bedingungen und Status des Schreibvorgangs. Zugangsdaten und unnötige personenbezogene Inhalte gehören nicht in das Protokoll.

Fehlende Datensätze in Automationen: So findest du die Lücke