> For the complete documentation index, see [llms.txt](https://one-loop.gitbook.io/help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://one-loop.gitbook.io/help/plattform/one-loop-plattform/automatisierung/workflows/workflow-ausfuhrungen-und-fehler-nachvollziehen.md).

# Workflow-Ausführungen und Fehler nachvollziehen

## Kurz erklärt

Ein Workflow arbeitet im Hintergrund Schritt für Schritt. Das **Ausführungsprotokoll** zeigt dir für einen konkreten Kontakt, was dabei tatsächlich passiert ist: welcher Schritt ausgeführt wurde, wann er lief, ob er noch wartet oder fehlgeschlagen ist und welche Daten zu diesem Ereignis gehören. Die **Teilnahmehistorie** zeigt dagegen den gesamten Durchlauf eines Kontakts – vom Eintritt bis zum Abschluss oder Austritt.

Beide Ansichten helfen dir, nicht nach Gefühl zu ändern: Du kannst erst nachvollziehen, was passiert ist, und anschließend nur den wirklich betroffenen Schritt anpassen.

## Voraussetzungen

* Du hast Zugriff auf **Automatisierung** und **Workflows**.
* Der betreffende Kontakt ist bereits in den Workflow eingetreten oder es gibt eine betroffene Nachricht in der Inbox.
* Für eine aussagekräftige Prüfung kennst du möglichst den ungefähren Zeitpunkt und die erwartete Aktion, zum Beispiel: „Nach dem Absenden des Formulars sollte eine Bestätigung gesendet werden.“

> **Wichtig:** Ausführungsprotokolle stehen nur für die vergangenen 30 Tage zur Verfügung. Prüfe einen neuen Fehler deshalb zeitnah.

## Was du in den beiden Ansichten siehst

| Ansicht                  | Beantwortet diese Frage                                                 | Typische Nutzung                                                                                              |
| ------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Ausführungsprotokoll** | Was ist bei einer einzelnen Aktion passiert?                            | Eine Nachricht wurde nicht gesendet oder ein Schritt zeigt einen Fehler.                                      |
| **Teilnahmehistorie**    | Wie ist ein Kontakt insgesamt durch den Workflow gelaufen?              | Du möchtest prüfen, ob der Kontakt eingetreten ist, welchen Pfad er genommen hat und warum der Ablauf endete. |
| **Ausführungshistorie**  | Was geschah in genau einem bestimmten Durchlauf?                        | Derselbe Kontakt war mehrmals im selben Workflow.                                                             |
| **Kontaktverlauf**       | Was geschah bei diesem Kontakt über alle Teilnahmen an diesem Workflow? | Du möchtest frühere und aktuelle Durchläufe miteinander vergleichen.                                          |

## Konfigurationsfehler vor der Aktivierung finden

Fehler lassen sich oft bereits im Builder finden, bevor ein Kontakt betroffen ist:

1. Öffne den Workflow im Builder.
2. Achte auf Warnsymbole an Auslösern oder Aktionen.
3. Öffne in der Seitenleiste **Fehler**, um alle erkannten Punkte zusammen zu sehen.
4. Wähle einen Eintrag. Die Liste nennt den betroffenen Schritt und erklärt, was fehlt oder nicht verbunden ist.
5. Öffne die betroffene Konfiguration und ergänze die fehlende Angabe oder prüfe die Verbindung.
6. Speichere den Workflow erneut.

Beim Speichern werden auch Wenn/Dann-Verzweigungen und Wartezeiten geprüft. Fehlt dort eine notwendige Auswahl, wird der Schritt direkt markiert und im Fehlerbereich aufgeführt.

Der Fehlerbereich unterscheidet insbesondere zwischen fehlenden Pflichtangaben und Problemen mit einer verbundenen Funktion. Ein Hinweis bedeutet nicht automatisch, dass ein bereits aktiver Workflow deaktiviert wird. Er bleibt in seinem bisherigen Zustand, bis du selbst eine Änderung vornimmst.

### Hilfe durch KI sinnvoll nutzen

Wenn neben einem Fehler **Mit KI lösen** erscheint, erklärt dir die Funktion die mögliche Ursache und passende Prüfschritte. Sie kann den betroffenen Schritt für dich öffnen. Prüfe die vorgeschlagene Lösung trotzdem immer selbst:

* Stimmen die ausgewählten Werte mit deinem gewünschten Ablauf überein?
* Sind die nötigen Daten am Kontakt vorhanden?
* Ist eine erforderliche Verbindung noch gültig?
* Hast du die Änderung gespeichert?

Sobald der Fehler behoben ist, verschwindet das Warnsymbol und der Eintrag aus der Fehlerliste. In den Einstellungen der Seitenleiste kannst du die Sichtbarkeit des Fehlerbereichs bei Bedarf an- oder ausschalten.

## Schritt für Schritt

### Ausführungsprotokoll im Workflow öffnen

1. Öffne **Automatisierung** und danach **Workflows**.
2. Öffne den betroffenen Workflow.
3. Wähle oben **Ausführungsprotokoll**.
4. Stelle zuerst einen passenden Zeitraum ein.
5. Grenze die Liste bei Bedarf nach Aktion, Status oder Kontakt ein.
6. Suche die passende Zeile und wähle **Details anzeigen**.

Eine geöffnete Zeile bleibt optisch hervorgehoben. So erkennst du auch in längeren Listen, welchen Ereigniseintrag du gerade untersuchst.

### Eine Zeile richtig lesen

In der Liste siehst du pro Ereignis mindestens den Kontakt, die Aktion, den Status und den Zeitpunkt unter **Ausgeführt am**. Öffne **Details anzeigen**, um den Ereigniskontext zu prüfen.

Achte besonders auf diese Punkte:

* **Aktion:** Im Protokoll erscheint der Name, den du dem Schritt gegeben hast. Bei mehreren gleichartigen Schritten ist das hilfreicher als nur der Aktionstyp. Fahre mit der Maus über den Namen, wenn du zusätzlich den zugrunde liegenden Typ sehen möchtest.
* **Status:** Ein wartender Schritt ist nicht automatisch fehlerhaft. Ein Fehler ist dagegen im Status oder bei **Details anzeigen** hervorgehoben.
* **Ausgeführt am:** Prüfe Datum, Uhrzeit und die angezeigte Zeitzone zusammen. Die Oberfläche kann das Datum kompakt darstellen; die genaue Uhrzeit erscheint dann beim Darüberfahren.
* **Details:** Hier siehst du den zugehörigen Kontakt, den ausgeführten Schritt, den Ereignisstatus und – soweit vorhanden – die technischen Ereignisdetails. Teile keine unnötigen Kontakt- oder technischen Daten, wenn du den Vorgang intern weitergibst.

### Direkt aus einer Nachricht zur richtigen Ausführung springen

Wenn du bereits weißt, welche Nachricht betroffen ist, musst du nicht erst in einer langen Protokollliste suchen:

1. Öffne die **Inbox** und dann die betroffene Unterhaltung.
2. Wähle die Nachricht, bei der du einen Fehler oder eine unerwartete Aktion vermutest.
3. Öffne die Nachrichtendetails.
4. Wähle im Bereich **Workflow** den verlinkten Workflow.
5. Das Ausführungsprotokoll öffnet sich direkt mit der passenden Ausführung und dem betreffenden Kontakt.

So prüfst du genau den Durchlauf, der zu dieser Nachricht gehört.

### Kontaktpfad im Builder sichtbar machen

Der Kontaktpfad macht den tatsächlichen Weg im Builder sichtbar:

1. Öffne die Teilnahmehistorie oder die Ausführungshistorie eines Kontakts.
2. Wähle **Kontaktpfad hervorheben**.
3. Der Builder öffnet sich und markiert den tatsächlichen Weg dieses Kontakts.
4. Prüfe dort:
   * Schritte mit einem Fehler,
   * übersprungene Schritte,
   * den Eintritt und Austritt,
   * ob der Kontakt noch aktiv durch den Workflow läuft.
5. Wähle bei einem fehlerhaften Schritt **Zur Aktion**, um die betroffene Konfiguration direkt im Builder zu öffnen.
6. Teste die Änderung anschließend mit einem geeigneten Testkontakt.

Der Kontaktpfad erklärt, warum ein Kontakt einen bestimmten Zweig genommen hat. Er zeigt nicht, was ein anderer Kontakt im selben Workflow erlebt hat.

### Zeitraum und Liste sinnvoll eingrenzen

1. Öffne die Filter im Ausführungsprotokoll oder in der Teilnahmehistorie.
2. Wähle einen vorhandenen Zeitraum oder setze einen eigenen Start- und Endzeitpunkt.
3. Ein eigener Zeitraum darf höchstens 30 Tage umfassen.
4. Filtere bei Bedarf nach Aktion, Status oder einem einzelnen Kontakt.
5. Wenn du nach einer Aktion filterst, stehen die Aktionen des aktuellen Workflows zuerst. Weitere Aktionen werden getrennt aufgeführt.
6. Aktualisiere die Liste nach einer Änderung mit dem Aktualisieren-Symbol.
7. Wähle 10, 25 oder 50 Einträge pro Seite, wenn die Liste länger ist.

Diese Filter ändern nichts am Workflow. Sie helfen nur, die passende Ausführung schneller zu finden.

## Fehlerbenachrichtigungen einrichten

Zusätzlich zum Ausführungsprotokoll kannst du E-Mail-Hinweise für neue Workflow-Fehler aktivieren.

1. Öffne in **Automatisierung > Workflows** die **Workflow-Einstellungen**.
2. Öffne den Bereich **Benachrichtigungen**.
3. Aktiviere die E-Mail-Benachrichtigung.
4. Lege die Personen fest, die Fehler prüfen sollen.
5. Speichere die Einstellung.

Die Benachrichtigung ist zunächst ausgeschaltet. Neue Empfänger können ergänzt und nicht mehr zuständige Personen entfernt werden.

Die Übersicht **Prüfung erforderlich** in der Workflow-Liste zeigt Workflows mit noch zu prüfenden Fehlern aus den vergangenen 30 Tagen. Öffne den Eintrag, springe in das Ausführungsprotokoll und prüfe die konkrete Aktion. Erst danach wählst du **Als gelesen markieren**.

> **Als gelesen markieren** bestätigt nur, dass der Hinweis geprüft wurde. Es behebt weder die Ursache noch wiederholt es einen fehlgeschlagenen Schritt.

Bei einem neuen Fehler wird ein Hinweis versendet. Innerhalb von 24 Stunden wird höchstens eine E-Mail versendet; werden nach diesem Zeitraum weitere Fehler erkannt, folgt ein neuer Hinweis. Prüfe deshalb regelmäßig die Übersicht und das Ausführungsprotokoll, statt dich ausschließlich auf E-Mails zu verlassen.

## Ergebnis sicher prüfen

Nach einer Korrektur solltest du nicht nur kontrollieren, ob das Warnsymbol verschwunden ist. Prüfe den gesamten Ablauf:

1. Verwende einen frischen Testkontakt, der den Workflow noch nicht durchlaufen hat.
2. Löse die gewünschte Bedingung aus, zum Beispiel das Absenden eines Formulars.
3. Prüfe, ob der Kontakt in der Teilnahmehistorie erscheint.
4. Öffne das Ausführungsprotokoll und kontrolliere Aktion, Status, Zeitpunkt und Kontaktpfad.
5. Prüfe das tatsächliche Ergebnis außerhalb des Workflows, zum Beispiel die gesendete Nachricht oder die geänderte Information.
6. Wenn der Kontakt erneut eintreten soll, kontrolliere zusätzlich die Einstellungen für wiederholte Eintritte.

Ein Test mit einem bereits verwendeten Kontakt kann ein anderes Ergebnis liefern, weil dessen frühere Teilnahme den Ablauf beeinflussen kann.

## Häufige Fälle und ihre Lösung

### Falschen Kontakt oder falsche Ausführung geprüft

Ein Kontakt kann denselben Workflow mehr als einmal durchlaufen. Öffne die **Ausführungshistorie**, wenn du genau einen bestimmten Durchlauf prüfen möchtest. Der **Kontaktverlauf** zeigt dagegen alle Teilnahmen dieses Kontakts am selben Workflow.

### Aktion nur am Typ erkannt

Vergib für wichtige Aktionen aussagekräftige Namen, zum Beispiel „Bestätigung nach Formular“ statt nur „E-Mail“. Im Protokoll wird dieser Name angezeigt. Bei gleichartigen Aktionen kannst du den Typ zusätzlich beim Darüberfahren prüfen.

### Kontakt hat den Workflow verlassen

Die Teilnahmehistorie unterscheidet unter anderem zwischen:

* **Workflow abgeschlossen:** Der Kontakt hat den Ablauf regulär beendet.
* **Durch Workflow-Aktion entfernt:** Ein Schritt im aktuellen Workflow hat den Kontakt entfernt.
* **Durch Aktion eines anderen Workflows entfernt:** Ein anderer Workflow hat die Entfernung ausgelöst.

Prüfe diesen Status vor jeder Änderung. Nicht jeder Austritt ist ein Fehler.

### Kontakt wurde zusammengeführt

Wenn doppelte Kontakte zusammengeführt werden, kann das Protokoll einen entsprechenden Eintrag zeigen. Der laufende Ablauf wird dann dem verbleibenden Kontakt zugeordnet. Prüfe bei Unklarheiten den Kontaktverlauf, bevor du denselben Workflow erneut auslöst.

### Datum oder Uhrzeit wirken falsch

Prüfe Datum, Uhrzeit und die verwendete Zeitzone zusammen. Ein Eintrag ohne sichtbare Uhrzeit ist nicht unvollständig – je nach Ansicht wird sie erst beim Darüberfahren angezeigt.

### Keine Einträge gefunden

Prüfe zuerst den Zeitraum. Liegt der Vorgang länger als 30 Tage zurück, steht dafür kein Ausführungsprotokoll mehr zur Verfügung. Prüfe außerdem, ob ein Aktions-, Status- oder Kontaktfilter die gesuchte Zeile ausblendet.

## Praxisbeispiel: Eine Bestätigung wurde nicht gesendet

Ein Kontakt füllt ein Formular aus, erhält aber keine erwartete Bestätigung.

1. Die zuständige Person öffnet die betreffende Nachricht in der Inbox und folgt dem Workflow-Link in den Nachrichtendetails.
2. Im Ausführungsprotokoll öffnet sie **Details anzeigen** bei der betroffenen Aktion.
3. Der Status zeigt einen Fehler. Über **Zur Aktion** öffnet sie den Schritt im Builder.
4. Dort ergänzt sie die fehlende Einstellung, speichert den Workflow und prüft, dass das Warnsymbol verschwunden ist.
5. Sie verwendet einen neuen Testkontakt, füllt das Formular aus und kontrolliert anschließend das Protokoll sowie die tatsächlich eingegangene Bestätigung.
6. Erst wenn beides stimmt, markiert sie den ursprünglichen Hinweis als gelesen.

So bleibt nachvollziehbar, was passiert ist, wie die Ursache behoben wurde und ob die Korrektur tatsächlich wirkt.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://one-loop.gitbook.io/help/plattform/one-loop-plattform/automatisierung/workflows/workflow-ausfuhrungen-und-fehler-nachvollziehen.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
