Ausführungsverlauf und Problemanalyse
Der Ausführungsverlauf beantwortet die zentrale Frage der Automatisierungskontrolle: Hat die Aufgabenregel, der Roboter oder der Geschäftsprozess ausgelöst, und wenn nicht – warum? Ohne ihn ist unklar, ob die Automatisierung tatsächlich arbeitet oder still stillsteht. Diese Seite handelt davon, wie man die Ausführungsergebnisse liest und typische Probleme analysiert.
Der Verlauf ist dort verfügbar, wo jede Engine lebt: bei den Aufgabenregeln – auf dem Tab „Verlauf", bei den CRM-Robotern und Geschäftsprozessen – in deren Bereichen.
Wo der Verlauf zu finden ist
- Aufgabenregeln – Tab „Verlauf" unter
/tasks/automation: Auslöseeinträge nach Aufgaben; - CRM-Roboter – Auslöseverlauf nach Deals in der CRM-Automatisierung;
- Geschäftsprozesse – Schrittverlauf in der Karte der Instanz und Zusammenfassung der „fälligen auszuführenden Schritte";
- verzögerte Schritte – Zusammenfassung des Durchlaufs: wie viele verarbeitet, erfolgreich und fehlgeschlagen sind.
Beginnen Sie die Analyse mit der Engine, deren Verhalten Sie überrascht hat, und öffnen Sie deren Verlauf für das konkrete Objekt.
Was ein Verlaufseintrag zeigt
Jeder Verlaufseintrag beschreibt eine Ausführung:
- Status – womit die Ausführung endete;
- Zeit – wann sie ausgelöst oder geplant wurde;
- Objekt – die Aufgabe oder der Deal, für den die Ausführung lief;
- Grund – Code/Erklärung, falls die Ausführung nicht durchgeführt wurde;
- Meldung – Text über den Fehler oder das Ergebnis.
Die Verbindung „Status + Grund" ist das wichtigste Analysewerkzeug: Der Status sagt, was geschehen ist, der Grund warum.
Ergebnisse der Ausführung
Eine Ausführung endet mit einem dieser Ergebnisse:
- erfolgreich – die Aktion wurde durchgeführt;
- übersprungen – die Bedingung war nicht erfüllt oder die Ausführung war nicht zugelassen, daher wurde die Aktion nicht angewendet;
- fehlgeschlagen – die Aktion hätte ausgeführt werden sollen, konnte es aber nicht;
- blockiert – eine Schutzprüfung hat den Vorgang gestoppt.
Übersprungen und blockiert sind kein Fehler, sondern reguläres regelkonformes Verhalten; fehlgeschlagen ist das, was eine Analyse erfordert.
Warum eine Regel übersprungen wurde
„Übersprungen" bedeutet in der Regel, dass die Ausführung nach Bedingungen oder Berechtigungen nicht passte:
- die Bedingungen der Regel waren für dieses Objekt nicht erfüllt;
- der Geltungsbereich schließt dieses Projekt, diesen Trichter oder diese Phase nicht ein;
- der Ausführende oder die Regel hat keine Berechtigungen für die nötige Aktion.
Das ist normal: Die Regel rührt absichtlich nicht an, was außerhalb ihrer Bedingungen liegt. Wenn sie hätte auslösen sollen – sind die Bedingungen oder der Geltungsbereich zu eng oder falsch.
Warum eine Ausführung blockiert wurde
„Blockiert" bedeutet, dass eine Schutzprüfung ausgelöst hat: Der Vorgang wurde nicht durchgeführt, weil eine Pflichtbedingung nicht erfüllt war (zum Beispiel ein nicht ausgefülltes Feld vor dem Phasenwechsel). Das ist kein Automatisierungsfehler, sondern eine greifende Regel. Analysieren Sie anhand der Meldung der Prüfung: Sie erklärt, was ausgefüllt oder abgeschlossen werden muss.
Warum ein Schritt fehlgeschlagen ist
„Fehlgeschlagen" bedeutet, dass die Aktion hätte ausgeführt werden sollen, es aber nicht konnte. Häufige Gründe: Der Ausführende der Aktion hat keine Berechtigungen, ein nötiger Teilnehmer oder ein Objekt fehlt, die Aktion ist falsch konfiguriert, ein externer Vorgang ist nicht verfügbar (zum Beispiel der Versand einer E-Mail ohne aktive Vorlage). Sehen Sie sich die Meldung des Eintrags an – sie weist auf den konkreten Grund hin.
Teilergebnis
Bei Robotern und Durchläufen der „fälligen auszuführenden Schritte" ist ein Teilergebnis möglich: Ein Teil der Kette oder ein Teil der verzögerten Schritte wurde ausgeführt, ein Teil nicht. Beim Roboter hängt das von der Fehlerrichtlinie ab (anhalten oder fortfahren), beim Durchlauf ist es an der Zusammenfassung sichtbar (verarbeitet/erfolgreich/fehlgeschlagen). Ein Teilergebnis ist gefährlicher als ein vollständiger Fehler: Das Objekt bleibt in einem halb verarbeiteten Zustand, daher werden solche Einträge zuerst analysiert.
Typische Korrekturen
- übersprungen, hätte aber auslösen sollen – prüfen Sie die Bedingungen und den Geltungsbereich;
- blockiert – erfüllen Sie die Anforderung der Schutzprüfung oder passen Sie die Prüfung selbst an;
- Berechtigungsfehler – erteilen Sie dem Ausführenden der Aktion Berechtigungen oder wechseln Sie den Ausführenden;
- Fehler beim E-Mail-Versand – prüfen Sie, dass die Vorlage aktiv ist und die Variablen korrekt sind;
- wiederkehrender Fehler an einem Schritt – reparieren Sie die Regel, den Roboter oder die Prozessvorlage, nicht das Objekt von Hand.
Gute Praktiken
- Sehen Sie sich den Verlauf regelmäßig an, nicht nur wenn etwas kaputtgegangen ist.
- Unterscheiden Sie das reguläre „übersprungen/blockiert" von einem echten „fehlgeschlagen".
- Analysieren Sie Teilergebnisse zuerst.
- Beheben Sie die Ursache in der Automatisierungskonfiguration, nicht die Folge von Hand.
- Halten Sie wiederkehrende Fehler als Signal zur Überprüfung der Regel oder des Geschäftsprozesses fest.
Häufige Fehler
„Übersprungen" für eine Störung halten. Meistens rührt die Regel absichtlich nicht an ein Objekt außerhalb der Bedingungen.
Das Objekt von Hand reparieren statt die Ursache. Der Fehler wiederholt sich bei der nächsten Ausführung.
Das Teilergebnis ignorieren. Das Objekt bleibt in einem inkonsistenten Zustand.
Meldung und Grund nicht lesen. Sie weisen direkt darauf hin, was zu beheben ist.
Wie man prüft, dass es repariert ist
- eine erneute Ausführung (oder ein manueller Durchlauf) endet erfolgreich;
- der Verlaufseintrag zeigt den erwarteten Status ohne Fehler;
- blockierte Ausführungen sind verschwunden, nachdem die Anforderung der Prüfung erfüllt wurde;
- Teilergebnisse sind zu Ende geführt, das Objekt ist in einem korrekten Zustand;
- der wiederkehrende Fehler erscheint nicht mehr im Verlauf.