Wenn eine Fin Procedure eine Konversation nicht wie erwartet löst, können Sie integrierte Inspektionswerkzeuge nutzen, um Fin's Entscheidungslogik zu untersuchen. Verwenden Sie diese Anleitung, um zu erkennen, wo ein Ablauf abgewichen ist und wie Sie Ihre Anweisungen verfeinern.

Das lernen Sie

Fehler bei Procedures mit Fin's Gedanken und Konversationsereignissen debuggen.
Häufige Probleme wie falsche Procedure-Auslöser, Schritte außerhalb der Reihenfolge und Verzweigungsfehler diagnostizieren.
Fehler bei Data connector beheben, einschließlich Authentifizierungsfehler und fehlender Daten.
Korrekturen vor dem Livegang mit Simulationen validieren.

Zugriff auf den Konversations-Debugger

Um zu verstehen, warum Fin eine bestimmte Aktion ausgeführt hat, müssen Sie zuerst die technische Sichtbarkeit im Konversationsverlauf aktivieren.

Öffnen Sie die spezifische Konversation im Inbox.
Klicken Sie auf das Symbol mit den drei Punkten oben rechts in der Kopfzeile der Konversation.
Wählen Sie Konversationsereignisse anzeigen.

Tipp: Verwenden Sie die Tastenkombination ⌘ + E (Mac) oder Strg + Umschalt + E (Windows), um diese Ansicht umzuschalten.

Inspektion von "Fin's Gedanken"

Sobald Konversationsereignisse sichtbar sind, können Sie die Begründung hinter jedem Schritt sehen, den Fin während einer Procedure unternommen hat. Um Fin’s Entscheidungsprozess nachzuvollziehen, suchen Sie die Fin's thoughts-Ereignisse in der Konversationszeitleiste. Diese Ereignisse fassen Fin’s Überlegungen zusammen, bevor eine Nachricht gesendet oder eine Aktion ausgeführt wird.

Für detailliertere Informationen klicken Sie auf Fin Thoughts und dann auf Mehr anzeigen. Dies zeigt:

Der aktuelle Schritt: Der spezifische Procedure-Schritt, den Fin gerade ausführte.
Absichtsauslegung: Wie Fin die Anfrage des Kunden verstanden hat.
Logikpfad: Warum Fin entschieden hat, einen Schritt zu überspringen, einen vorherigen erneut zu besuchen oder zu einem bestimmten Zweig zu wechseln.

Wenn Fin eine Procedure für eine Kundenanfrage in Betracht zieht, diese aber nicht ausführt, erscheint ein "[Procedure-Name] von Fin in Betracht gezogen und abgelehnt"-Ereignis in der Konversationszeitleiste neben den regulären Auslöserereignissen. Erweitern Sie es, um Fin's Begründung für die Ablehnung zu lesen.

Hinweis: Dieser Artikel behandelt nur die Fehlerbehebung für Fin Procedures. Die "Fin's thoughts"-Zeitleiste und der Debugger sind nur verfügbar, wenn eine Procedure ausgelöst wurde. Wenn Fin in einer Standardkonversation eine unerwartete Antwort gab, sind diese Werkzeuge in den Konversationsereignissen nicht vorhanden.

Häufige Fehler bei Procedures

Wenn Fin nicht wie erwartet funktioniert, liegt es meist an der Formulierung der Anweisungen oder der Verzweigungslogik.

Procedure wird überhaupt nicht ausgelöst

Bevor Sie die unten nummerierten Fehler überprüfen, gehen Sie zuerst diese Grundlagen durch:

Überprüfen Sie, ob die Procedure veröffentlicht ist: Entwurfs-Procedures werden für Kunden nicht ausgelöst. Stellen Sie sicher, dass der Status im Editor auf Published gesetzt ist.
Überprüfen Sie, ob Fin bereitgestellt ist: Wenn Fin nicht über den Simply Deploy-Bereich aktiviert ist oder der Schritt "Let Fin handle" in Ihrem workflow nicht live ist, führt Fin keine Procedures aus.
Überprüfen Sie die Zielgruppenansprache: Ein häufiger Fehler ist, Users anzusprechen, wenn der Kunde ein Lead ist (oder umgekehrt). Klicken Sie im Abschnitt "When to use this procedure" auf die Zielgruppenschaltfläche und vergewissern Sie sich, dass der richtige Publikumstyp und Kanal ausgewählt sind.
Überprüfen Sie auf Workflows mit höherer Priorität: Aktive Workflows laufen, bevor Fin die Procedure-Absicht bewertet. Prüfen Sie Ihre workflows, um sicherzustellen, dass keine die Konversation abfängt, bevor Fin die Procedure auslösen kann.
Überprüfen Sie den Umfang der Auslösekriterien: Zu enge Kriterien verhindern, dass Fin gültige Kundenanfragen erkennt. Prüfen Sie die Beschreibung "When to use this procedure" und fügen Sie positive Beispiele (Nachrichten, die die Procedure auslösen sollten) und negative Beispiele (Nachrichten, die sie nicht auslösen sollten) hinzu.
Überprüfen Sie auf konkurrierende Escalation Guideline oder Escalation Rule: Wenn die Kundenanfrage auch auf eine Escalation Guideline oder Escalation Rule (Fin AI Agent > Train > Escalations) passt, hat die Eskalation Vorrang – Fin übergibt an einen Menschen, anstatt die Procedure auszulösen, selbst wenn die Auslösekriterien der Procedure gleichwertig oder besser passen. Überprüfen Sie Ihre Escalation Guidance und Escalation Rules auf Formulierungen, die mit den Auslösern der Procedure übereinstimmen (z. B. denselben Fehlercode oder Ausdruck), und fügen Sie positive und negative Beispiele zur Escalation Guideline hinzu, wie Sie es auch für die Procedure-Auslöser tun, damit beide nicht um dieselbe Nachricht konkurrieren.

Hinweis: Obwohl Slack als auswählbarer Kanal erscheint, werden Procedure-Auslöser für Slack-Konversationen derzeit nicht unterstützt.

Fin löst die falsche Procedure aus

Problem: Fin startet eine Procedure, die nicht zur Kundenanfrage passt.

Lösung: Überprüfen Sie Ihre "When to use this procedure"-Anweisungen. Verwenden Sie positive und negative Beispiele, um Fin bei der Unterscheidung ähnlicher Absichten zu helfen. Wenn eine neue Procedure ähnliche Auslösekriterien wie eine bereits veröffentlichte Procedure hat, kann die veröffentlichte Vorrang haben. Um die neue Procedure während des Tests zu isolieren: schließen Sie Ihren Testnutzer vorübergehend von der bestehenden Procedure aus, indem Sie die Zielgruppenkriterien anpassen, oder verengen Sie den Auslöser der neuen Procedure auf eine einzigartige Phrase, die nur Sie senden würden. Verwenden Sie Fin's thoughts > Expand thoughts im Konversations-Debugger, um zu bestätigen, welche Procedure tatsächlich ausgelöst wurde.

Verwendung von Fin Operator zum Debuggen von Procedure-Auslösern

Der Konversations-Debugger von Fin Operator zeigt genau, was mit einer Procedure in einer bestimmten Konversation passiert ist. Fragen Sie Operator nach einer Konversation, und er berichtet, ob jede Procedure ausgelöst, abgelehnt, bereits aktiv, nie in Betracht gezogen oder von einer besser passenden Procedure oder Escalation Guideline übertroffen wurde – und schlägt eine Lösung für den jeweiligen Fall vor.

Verwendung von Fin Operator zur Überprüfung von Procedure-Auslösern

Wenn Sie Fin Operator bitten, den Auslöser einer Procedure (die Beschreibung und Beispiele unter "When to use this procedure") zu überprüfen oder zu schreiben, weist er auf die zwei Fehler hin, die am häufigsten verhindern, dass eine Procedure ausgelöst wird: Bedingungen, die in Begriffen formuliert sind, die ein Kunde selbst nicht äußern würde (z. B. ein interner Kontostatus, den der Kunde nicht erwähnen würde), und eine breite Auslöserbeschreibung, die mit engen Auslöserklauseln kombiniert ist, die den Beispielen der Beschreibung widersprechen.

Schritte außerhalb der Reihenfolge

Problem: Fin überspringt einen erforderlichen Schritt oder geht zu früh zu einer Lösung über.

Lösung: Prüfen Sie Ihre Anweisungen auf Mehrdeutigkeit. Wenn ein Schritt von einem bestimmten Datenelement abhängt, stellen Sie sicher, dass die Anweisung ausdrücklich lautet: "Nur fortfahren, wenn [Daten] bereitgestellt werden."

Fehler in der Verzweigungslogik

Problem: Fin folgt dem "Else"-Pfad, obwohl es dem "If"-Pfad hätte folgen sollen.

Lösung: Überprüfen Sie die Bedingungen. Wenn Sie natürliche Sprache für Verzweigungen verwenden, versuchen Sie, die Formulierung zur Klarheit zu überarbeiten. Für komplexe Logik (z. B. Datumsberechnungen) sollten Sie Python-Codeblöcke verwenden, um strikte deterministische Regeln durchzusetzen.

Help Center-Inhalte haben Vorrang

Problem: Fin antwortet aus dem Help Center, anstatt die Procedure auszuführen, obwohl die Kundenabsicht klar den Auslösekriterien der Procedure entspricht.

Lösung: Wenn Fin standardmäßig eine Help Center-Antwort gibt, anstatt die Procedure auszuführen, gibt es je nach Einrichtung zwei Ansätze. Versuchen Sie zuerst Option 1 – wenn das Problem weiterhin besteht, wechseln Sie zu Option 2.

Option 1: Procedure Switching aktivieren
Agentic Switch ist eine pro-Verfahren-Einstellung, die es Fin ermöglicht, automatisch von dem aktuellen Verfahren zu einem anderen aktiven Verfahren zu wechseln, wenn erkannt wird, dass sich die Absicht eines Kunden mitten im Gespräch geändert hat – anstatt am ursprünglichen Verfahren festzuhalten oder auf eine Help Center-Antwort zurückzugreifen. Wenn aktiviert:
- Fin überprüft das Gespräch und alle Beschreibungen der Auslöser für aktive Verfahren, um zu entscheiden, wann ein Wechsel dem Kunden besser dienen würde.
- Wenn mehrere Verfahren zutreffen könnten, kann Fin eine klärende Frage stellen, um das beste auszuwählen.
- Nur das Quellverfahren (das Verfahren, aus dem Fin wechselt) muss die Einstellung aktiviert haben.
- Der @Switch-Befehl kann weiterhin verwendet werden, um manuell zu wechseln.
Um es zu aktivieren: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Option 2: Entfernen oder Aktualisieren von widersprüchlichen Help Center-Inhalten
Wenn die Aktivierung von Agentic Switch das Problem nicht löst, ist die zuverlässigste Lösung, die Help Center-Inhalte zu entfernen oder zu aktualisieren, die Fin anzeigt, anstatt das Verfahren auszuführen. Fin greift standardmäßig auf Help Center-Antworten zurück, wenn relevante Inhalte zu einem Thema vorhanden sind – wenn also ein Artikel dieselbe Absicht wie Ihr Verfahren abdeckt, antwortet Fin direkt daraus, anstatt das Verfahren auszulösen.

Um die widersprüchlichen Inhalte zu identifizieren:
- Finden Sie das Gespräch in Ihrem Inbox und öffnen Sie Fin's thoughts.
- Suchen Sie nach Verweisen auf Help Center-Artikel im Antwortpfad.
- Entfernen Sie entweder den widersprüchlichen Artikel oder aktualisieren Sie ihn, um Kunden anzuweisen, den Support zu kontaktieren, damit Fin stattdessen zum Verfahren weiterleitet.

Beispiel: Ein Unternehmen hat ein Verfahren, das Rückerstattungsanfragen bearbeitet – es sammelt die Bestellnummer, prüft die Berechtigung und verarbeitet die Rückerstattung automatisch. Sie haben auch einen Help Center-Artikel mit dem Titel „Wie bekomme ich eine Rückerstattung?“, der die Rückerstattungsrichtlinie erklärt. Wenn ein Kunde „Ich möchte eine Rückerstattung“ schreibt, findet Fin den Help Center-Artikel und antwortet mit der Richtlinienerklärung, anstatt das Verfahren auszulösen. In diesem Fall entfernt die Aktualisierung des Artikels mit einer Formulierung wie „Um eine Rückerstattung zu beantragen, starten Sie einen Chat und unser Assistent führt Sie durch den Prozess“ die widersprüchliche Antwort und leitet Kunden stattdessen zum Verfahren weiter.

Verfahren stockt oder beendet sich vor Abschluss

Problem: Das Verfahren erreicht einen bestimmten Schritt und stoppt oder endet in einem Endzustand, ohne alle erwarteten Schritte abzuschließen.

Lösung: Dies wird meist durch Designmuster verursacht, die Fins Fähigkeit verwirren, den aktuellen Verfahrensschritt zu verfolgen. Prüfen Sie Folgendes:

Überflüssige „Sofort fortfahren“-Anweisungen: Wenn mehrere Schritte Anweisungen wie „sofort zum nächsten Schritt fortfahren“ enthalten, kann Fin bereits abgeschlossene Schritte erneut bewerten, anstatt voranzuschreiten. Entfernen Sie diese Anweisungen und lassen Sie Fin den Ablauf natürlich basierend auf dem Fluss durchlaufen.
Anweisungen zum Überspringen von Schritten: Formulierungen wie „gehe zurück zu Schritt 2“ oder „wiederhole den Verifizierungsschritt“ können dazu führen, dass Fin zwischen Schritten hin- und herwechselt, anstatt voranzukommen. Gestalten Sie jeden Schritt so, dass es einen klaren Vorwärtspfad gibt.
Überlappende Bedingungslogik: Wenn zwei Bedingungen gleichzeitig als wahr bewertet werden können, kann Fin unvorhersehbar verzweigen oder stocken. Stellen Sie sicher, dass Ihre Bedingungen sich gegenseitig ausschließen – nur ein Zweig sollte zu einem Zeitpunkt wahr sein.
Sub-Verfahren endet ohne Fortsetzung: Wenn ein Sub-Verfahren abgeschlossen ist, das Hauptverfahren aber keine klare Anweisung für den nächsten Schritt hat, kann Fin das Ende des Sub-Verfahrens als Ende des gesamten Ablaufs behandeln. Fügen Sie im Schritt, der das Sub-Verfahren aufruft, eine explizite Anweisung hinzu: „Sobald das Sub-Verfahren abgeschlossen ist, fahre mit [Name des nächsten Schritts] fort.“

Verwenden Sie Fin's thoughts > Mehr anzeigen im Konversations-Debugger, um genau zu identifizieren, bei welchem Schritt Fin war, als das Verfahren unerwartet beendet wurde.

Attributtyp-Mismatch verursacht Speicherfehler

Problem: Das Verfahren schlägt fehl, wenn eine Antwort in einem Konversationsattribut gespeichert werden soll.

Lösung: Prüfen Sie, ob der Attributtyp mit dem Wert übereinstimmt, den das Verfahren speichern möchte. Wenn das Verfahren einen String speichert (z. B. eine während des Gesprächs gesammelte Kundenantwort), muss das Zielattribut vom Typ String sein. Die Verwendung eines Listenattributs mit demselben Namen führt zu Speicherfehlern. Um dies zu beheben, aktualisieren Sie entweder das Verfahren, um das korrekte Attribut zu referenzieren, oder ändern Sie den Attributtyp unter Settings > Data > Conversations.

Mobile (iOS)-Probleme mit Procedures

Auf Mobilgeräten (iOS) haben Procedures zusätzliche Anforderungen: Wenn ein Verfahren für eine bestimmte Frage in Betracht gezogen, aber abgelehnt wurde, zeigt der Batch-Test neben der Antwort „[Verfahrensname] würde in einem echten Kundengespräch in Betracht gezogen, aber abgelehnt“ an – klicken Sie auf Show reasoning, um zu sehen, warum Fin es nicht ausgelöst hat.

Nur Users: Procedures werden auf Mobilgeräten nur für Users ausgelöst – sie laufen nicht für Leads oder Besucher, unabhängig davon, wie die Zielgruppe im Verfahren konfiguriert ist.
iOS-Kanal muss ausgewählt sein: Im Abschnitt „Wann dieses Verfahren verwenden“ muss iOS als Kanal ausgewählt sein. Das Verfahren wird auf Mobilgeräten nicht ausgelöst, wenn nur Web aktiviert ist.
Verfahren muss veröffentlicht sein: Entwurfsverfahren werden mobilen Kunden nicht bereitgestellt.
Prüfen Sie, ob Fin für iOS bereitgestellt ist: Procedures benötigen Fin, das im iOS-Kanal live ist. Bestätigen Sie, dass Simple Deploy unter Fin AI Agent > Deploy > Chat aktiviert ist oder dass ein aktiver Let Fin Handle-Block im relevanten Workflow vorhanden ist, der iOS anvisiert.
Workflows mit höherer Priorität: Ein Workflow, der für denselben Gesprächsauslöser auf iOS läuft, kann das Gespräch abfangen, bevor Fin die Verfahrensabsicht bewertet. Überprüfen Sie Ihre aktiven Workflows auf Überschneidungen im iOS-Kanal.

Fehlerbehebung bei Datenverbindern in Procedures

Dieser Abschnitt behandelt Fehler, die speziell bei Datenverbindern innerhalb eines Verfahrens auftreten. Wenn Ihr Connector eigenständige Tests besteht, aber während eines Live-Verfahrens fehlschlägt, beginnen Sie hier.

Connector funktioniert im Test, aber nicht im Live-Verfahren

Problem: Der Connector besteht eigenständige Tests, schlägt aber während eines Live-Durchlaufs fehl.

Lösung: Dies wird meist durch eines der Folgenden verursacht:

Zugangsdaten: Speichern und veröffentlichen Sie nach dem Rotieren eines Schlüssels erneut. Prüfen Sie auf versteckte Zeichen wie nachgestellte Leerzeichen in Token-Werten.
Berechtigungen: Eine kürzliche Sicherheitsänderung in Ihrem externen System könnte den Zugriff entfernt haben.
IP-Whitelist: Bestätigen Sie, dass die ausgehenden IPs von Intercom enthalten sind. Kontaktieren Sie Ihren Account Manager für die aktuellen Bereiche.

Wichtig: Wenn Ihr Connector ohne Änderungen auf Ihrer Seite nicht mehr funktioniert, prüfen Sie, ob Ihr externer API-Anbieter (z. B. Shopify, Stripe) einen Endpunkt aktualisiert oder eingestellt hat.

401- und 403-Autorisierungsfehler

401 Unauthorized: Das Token fehlt, ist abgelaufen oder fehlerhaft. Intercom versucht automatisch einmal neu. Prüfen Sie im Tab Logs, ob ein Refresh versucht wurde.
403 Forbidden: Das Token ist gültig, hat aber keine Berechtigung. Überprüfen Sie die Berechtigungen in Ihrem externen System.
OAuth-Users: Verwenden Sie die Schaltfläche Reauthenticate anstelle des Löschens und Neuerstellens des Tokens.

Connector scheint nicht auszulösen

Prüfen Sie die Logs: Navigieren Sie zu Settings > Integrations > Data connectors > Logs. Wenn kein Log-Eintrag vorhanden ist, wurde der Schritt wahrscheinlich übersprungen; prüfen Sie die vorherige Verzweigungslogik.
Prüfen Sie die Gesprächsereignisse: Wählen Sie Logs bei jedem Fehlerereignis im Inbox für vollständige Details.

Connector liefert Daten, aber Fin nutzt sie nicht

Verwenden Sie Fin's thoughts, um zu sehen, wie Fin die Connector-Antwort interpretiert hat.
Machen Sie die Schrittanweisung expliziter: „Verwenden Sie @connector_name, um dies zu beantworten – verwenden Sie keine knowledge base-Inhalte.“
Überprüfen Sie, ob die Antwort leer oder null ist; Fin kann auf andere Quellen zurückgreifen, wenn keine verwertbaren Daten gefunden werden.
Fin ruft pro Runde einen Connector auf: Wenn Ihr Verfahren mehrere Connector-Aufrufe in Folge benötigt, muss jeder Aufruf ein eigener Schritt sein. Fin verarbeitet pro Gesprächsrunde nur einen Tool-Aufruf – es kann nicht mehrere Connector-Aufrufe in einem einzigen Schritt verketten.

Wichtig: Fin kann pro Runde nur einen Connector-Aufruf verarbeiten. Wenn Ihr MCP-Server zwei separate Antworten über denselben SSE-Stream sendet, kann Fin die erste Antwort nicht zuverlässig zur Erstellung seiner Antwort verwenden.

Connector erscheint nicht im Procedure Editor

Problem: Ihr Daten-Connector ist veröffentlicht und konfiguriert, erscheint aber nicht, wenn Sie versuchen, ihn in einem Schritt im Procedure Editor hinzuzufügen.

Lösung: Gehen Sie diese Prüfungen der Reihe nach durch:

Bestätigen Sie, dass der Connector auf Live gesetzt ist: Gehen Sie zu Einstellungen > Integrationen > Data connectors und prüfen Sie den Status des Connectors. Ein Connector im Entwurfsmodus erscheint nicht im Procedure Editor.
Vergewissern Sie sich, dass mindestens eine Aktion konfiguriert ist: Ein Connector ohne definierte Aktionen erscheint nicht als Option im Procedure Editor, auch wenn er auf Live steht.
Überprüfen Sie Ihre Rollenberechtigungen: Einige Rollen können Connectoren in den Einstellungen sehen, aber nicht im Procedure Editor darauf zugreifen. Stellen Sie sicher, dass Ihre Rolle Zugriff auf beide Bereiche hat.
Seite aktualisieren: Der Procedure Editor benötigt gelegentlich ein hartes Neuladen, um kürzlich veröffentlichte Connectoren anzuzeigen. Verwenden Sie ⌘ + Shift + R (Mac) oder Strg + Shift + R (Windows).
Kontaktieren Sie den Fin Support: Wenn keine der oben genannten Maßnahmen hilft, wenden Sie sich mit dem Connector-Namen und Ihren Workspace-Details an den Fin Support. Manche Workspace-Konfigurationen erfordern einen manuellen Schritt, um einen Connector im Procedure Editor verfügbar zu machen.

Connector schlägt im Auto-Execute-Modus fehl

Problem: Der Daten-Connector ist so konfiguriert, dass er automatisch ausgeführt wird – ohne Kundenaufforderung – schlägt aber während eines Live-Gesprächs still fehl. Fin eskaliert oder gibt eine unerwartete Antwort, und es gibt keinen sichtbaren Fehler im Gespräch.

Lösung: Im Auto-Execute-Modus kann Fin einen fehlgeschlagenen Connector-Schritt nicht überspringen und das Verfahren fortsetzen. Wenn der Connector einen Fehler zurückgibt, behandelt Fin den gesamten Schritt als nicht lösbar und eskaliert entweder an einen Menschen oder fällt auf das Standardverhalten zurück.

Es gibt zwei Möglichkeiten, damit umzugehen:

Ändern Sie Ihre externe API, um einen Fallback-Wert zurückzugeben: Statt einen Fehler zurückzugeben, wenn keine Daten verfügbar sind (z. B. 404, wenn eine Bestellung nicht gefunden wird), konfigurieren Sie Ihre API so, dass sie ein leeres oder Standardergebnis zurückgibt, auf das Fin reagieren kann. Dies ist die zuverlässigste Lösung, da Fin immer etwas erhält, mit dem es arbeiten kann.
Fügen Sie nach dem Connector-Aufruf einen Condition-Schritt hinzu: Verwenden Sie die status_code-Ausgabe des Connectors, um bei einem Fehler zu einer freundlichen Nachricht oder einem kontrollierten Eskalationspfad zu verzweigen. Siehe „Erweiterte Fehlerbehandlung mit status_code“ in diesem Artikel für die Einrichtung.

Connector gibt 404 zurück oder Kontaktattribute werden nicht geschrieben, obwohl der Connector ausgeführt zu sein scheint

Problem: Der Connector scheint ausgelöst zu werden – die Protokolle zeigen, dass er lief – gibt aber einen 404-Fehler zurück und Kontaktattribute werden nicht geschrieben, obwohl alle Connectoren korrekt konfiguriert sind.

Lösung: Dies wird fast immer durch eine ungültige Attribut-Pille in der Anforderungs-URL verursacht. Einer der URL-Parameter löst zur Laufzeit einen leeren Wert auf, wodurch die URL ungültig wird.

Die häufigste Ursache: Ein Attribut wurde manuell als {{Attributname}} eingegeben, anstatt es aus dem Attribute Inserter auszuwählen. Der Editor wandelt jeden {{...}}-Text in eine Pille um, die wie ein gültiges Attribut aussieht – aber wenn der Bezeichner keinem echten Attribut entspricht, wird er zur Laufzeit leer und die Anforderungs-URL ungültig.

So beheben Sie das:

Öffnen Sie den Connector und prüfen Sie die Anforderungs-URL und den Body auf Attribut-Pillen.
Löschen Sie alle manuell eingegebenen Pillen und ersetzen Sie sie, indem Sie das korrekte Attribut aus dem Attribute Inserter auswählen.
Wenn Ihre URL die Intercom-Kontakt-ID benötigt, wählen Sie Contact ID (user.id) aus dem Picker – nicht User ID (user_id). Die Contacts API erwartet die von Intercom generierte Kontakt-ID (user.id), nicht die extern gesetzte User-ID (user_id).

Connector-Ausgabe füllt keine Gesprächsattribute

Problem: Ein Daten-Connector-Schritt läuft und liefert die erwarteten Daten, aber der Wert erscheint nicht als Gesprächsattribut – spätere Schritte im Verfahren können nicht darauf zugreifen.

Lösung: Gesprächsattribute werden zu Beginn eines Gesprächs gesetzt und können während der Ausführung eines Verfahrens nicht in Echtzeit aktualisiert werden. Ein Connector, der innerhalb eines Verfahrens ausgeführt wird, kann während des Gesprächs kein neues Gesprächsattribut schreiben.

Was das in der Praxis bedeutet:

Verwenden Sie die Connector-Ausgabe direkt in späteren Schritten: Die Daten, die Ihr Connector zurückgibt, sind als Schrittausgabe im Verfahren verfügbar. Verweisen Sie in nachfolgenden Schritt-Anweisungen mit der Syntax @connector_name darauf. Der Wert ist im Verfahren zugänglich – erscheint aber nicht als Gesprächsattribut im Inbox.
Um Daten in einem Gesprächsattribut zu speichern: Verwenden Sie einen Handoff to workflow-Schritt und setzen Sie den Attributwert stattdessen im Workflow. Beachten Sie, dass das Verfahren nach der Übergabe nicht fortgesetzt wird, planen Sie Ihren Ablauf entsprechend.

Daten-Connector ist auf READ statt UPDATE gesetzt

Problem: Das Verfahren läuft, sammelt aber keine Kundeneingaben, obwohl der Daten-Connector-Schritt ausgeführt wird.

Lösung: Prüfen Sie den Aktionstyp des Daten-Connectors im betreffenden Schritt. READ prüft nur einen vorhandenen gespeicherten Wert – es fordert den Kunden nicht zur Eingabe auf und speichert keine neuen Daten. UPDATE sammelt Eingaben vom Kunden und speichert sie im Attribut. Wenn Ihr Verfahren Informationen vom Kunden sammeln soll (z. B. E-Mail-Adresse, Bestellnummer oder Kontaktgrund), wechseln Sie den Aktionstyp auf UPDATE.

Erweiterte Fehlerbehandlung mit status_code

Der status_code, der von einem Daten-Connector-Aufruf zurückgegeben wird, wird als Ausgabeattribut bereitgestellt. Sie können diesen in einem Condition step verwenden, um auf bestimmte HTTP-Antwortcodes zu verzweigen und so die Fehlerbehandlung von Fin präzise zu steuern, anstatt sich auf einen einfachen Erfolgs-/Fehlschlag-Zweig zu verlassen.

Zum Beispiel können Sie eine 404 (Ressource nicht gefunden) zu einer anderen Nachricht leiten als eine 500 (Serverfehler) oder nur bei einem bestimmten Fehlercode an einen menschlichen Agenten eskalieren.

Tipp: Siehe Wie man Code-Bedingungen für Fin Procedures schreibt für Codebeispiele zur Verwendung von status_code in einem Condition step.

Fehlerbehebungen mit Simulationen validieren

Bevor Sie Ihr Verfahren live schalten, verwenden Sie Simulationen, um die Fehlerbehebung zu überprüfen:

Vorschau vs. Simulationen – welche soll ich verwenden? Vorschau zeigt das vollständige Kundenerlebnis. Die Verwendung der Vorschau während das Verfahren live ist, kann Schritt-Nachrichten an echte Kunden ausgeben. Simulationen führen das Verfahren im Hintergrund ohne Kundenausgabe aus – sie sind die sicherste Methode, Logik und Trigger vor dem Livegang zu validieren.

Navigieren Sie zum Procedure Editor und klicken Sie auf Test.
Führen Sie eine Simulation durch, bei der die KI als Kunde im fehlerhaften Szenario agiert.
Überprüfen Sie das Bestehen/Nichtbestehen-Ergebnis und das KI-Urteil, um die Zuverlässigkeit der Logik zu bestätigen.

FAQs

Funktioniert der Conversation Debugger für Standard-Fin-Gespräche?

Nein, die „Fin’s thoughts“-Timeline und der Debugger sind nur verfügbar, wenn ein Procedure ausgelöst wurde. Wenn Fin in einem Standardgespräch eine unerwartete Antwort gab, sind diese Tools nicht vorhanden – prüfen Sie stattdessen die Inbox-Gesprächsereignisse.

Wie lange werden Data connector-Protokolle gespeichert?

Data connector-Antwortprotokolle werden standardmäßig bis zu 14 Tage gespeichert. Wenn Ihr Workspace strengere Datenschutzanforderungen hat, kann Intercom dies auf Anfrage auf 7 Tage reduzieren – wenden Sie sich an unser Support-Team, um dies zu aktivieren. Greifen Sie auf Ihre Protokolle unter Einstellungen > Integrationen > Data connectors > Logs zu.

Kann ich Simulationen verwenden, um Data connector-Antworten zu testen?

Ja – Simulationen führen die gesamte Procedure einschließlich aller Data connector-Schritte aus und sind somit die zuverlässigste Methode, um das Verhalten von Connectors vor dem Livegang zu validieren.

Warum wird meine Procedure von einem Workflow blockiert?

Workflows laufen, bevor Fin die Absicht der Procedure bewertet. Wenn ein Workflow für denselben Gesprächsauslöser aktiv ist, kann er das Gespräch weiterleiten, bevor Fin die Procedure zuordnen kann. Um das zu beheben: Überprüfen Sie Ihre aktiven workflows auf überlappende Auslöser und stellen Sie sicher, dass der Let Fin Handle-Block im Workflow-Pfad, in dem die Procedures verfügbar sein sollen, korrekt konfiguriert ist.

Warum wurde meine Procedure unerwartet an einen Menschen übergeben?

Es gibt zwei Möglichkeiten, wie eine Procedure an einen Menschen übergeben werden kann:

Standard-Eskalationsverhalten – Fin eskaliert automatisch basierend auf seiner eingebauten Logik: wenn ein Kunde klar darum bittet, mit einem Menschen zu sprechen, wenn Fin starke Frustration oder Ärger erkennt oder wenn der Kunde in einer sich wiederholenden Schleife feststeckt. Dies tritt immer auf, unabhängig davon, wie Ihre Procedure konfiguriert ist.
Konfigurierte Übergabe – Ein Handoff to team-Schritt, den Sie an einer bestimmten Stelle in der Procedure hinzugefügt haben, oder prozedurenspezifische Anweisungen, die Fin anweisen, in einem bestimmten Szenario zu übergeben.

Wenn die Übergabe unerwartet war, verwenden Sie Fin's thoughts im Konversations-Debugger, um zu sehen, welcher Typ ausgelöst wurde und an welchem Schritt.

Was passiert, wenn sowohl eine Procedure als auch eine Escalation Guideline auf dieselbe Kundenmeldung passen?

Die Eskalation hat Vorrang. Wenn eine Kundenmeldung sowohl die Auslöserkriterien einer Procedure als auch einer Escalation Guideline (oder einer Escalation Rule) erfüllt, übergibt Fin an einen Menschen, anstatt die Procedure auszuführen – selbst wenn der Auslöser der Procedure näher oder spezifischer zur Meldung passt. Dies ist eine allgemeine Regel, wie Fin konkurrierende Absichten auflöst, und kann nicht pro Procedure konfiguriert werden.

Zum Beispiel wird eine Procedure, die für "API Error"-Fallanfragen erstellt wurde, nicht ausgelöst, wenn ein Kunde einen API-Fehler beschreibt und gleichzeitig eine Escalation Guideline existiert, die auf "API Error"-Sprache reagiert – die Escalation Guideline gewinnt, und die Procedure wird nie ausgeführt.

Wie verhindere ich, dass eine Escalation Guideline unbeabsichtigt meine Procedure überlagert?

Eingrenzen der Escalation Guideline, sodass sie nicht mehr mit den Auslöserkriterien der Procedure überlappt:

Öffnen Sie Fin AI Agent > Train > Escalations und überprüfen Sie Ihre Escalation Guidance und Escalation Rules auf Formulierungen, die dieselben Nachrichten wie der Auslöser der Procedure treffen könnten.
Fügen Sie spezifische positive Beispiele (soll eskalieren) und negative Beispiele (soll nicht eskalieren – stattdessen soll die Procedure ausgeführt werden) zur Escalation Guideline hinzu, genauso wie Sie den Abschnitt "Wann diese Procedure verwenden" einer Procedure verfeinern würden.
Wenn beide auf denselben engen Ausdruck abzielen (z. B. einen spezifischen Fehlercode), formulieren Sie die Escalation Guideline so um, dass Fallanfragen ausgeschlossen werden, oder machen Sie die Auslöserkriterien der Procedure spezifischer, sodass sich die beiden nicht mehr überschneiden.

Verwenden Sie Fin's thoughts im Konversations-Debugger, um zu bestätigen, ob für eine gegebene Nachricht eine Eskalation oder die Procedure ausgelöst wurde (siehe "Zugriff auf den Konversations-Debugger" oben).

Warum wird meine Escalation Guidance innerhalb einer Procedure nicht ausgelöst?

Escalation Guidance gilt standardmäßig nicht innerhalb einer Procedure – Sie müssen sie explizit im Guidance-Panel der Procedure aktivieren:

Öffnen Sie Ihre Procedure, klicken Sie auf das Einstellungsrad oben rechts im Instructions-Editor und dann auf Guidance.
Wählen Sie die Guidance-Kategorien auf Workspace-Ebene aus, die Sie anwenden möchten, einschließlich Handover and escalation.
Fin kombiniert die ausgewählte Workspace-Guidance mit jeder prozedurenspezifischen Guidance, die Sie geschrieben haben.

Hinweis: Das Standard-Eskalationsverhalten von Fin (Kunde bittet um einen Menschen, Frustration erkannt, sich wiederholende Schleife) tritt immer innerhalb einer Procedure auf, unabhängig von den Guidance-Einstellungen. Das Guidance-Panel steuert nur Ihre Workspace-Escalation Guidance und Escalation Rules.

Was ist der Unterschied zwischen Handoff to team und Handoff to workflow?

Beide Schritte beenden die Procedure, leiten das Gespräch jedoch unterschiedlich weiter:

Handoff to team – Beendet die Procedure und übergibt das Gespräch an einen menschlichen Teamkollegen. Das Gespräch folgt dann dem Eskalationspfad, der in Ihrem Deploy workflow nach dem Let Fin handle-Schritt konfiguriert ist.
Handoff to workflow – Beendet die Procedure und übergibt das Gespräch an einen bestimmten wiederverwendbaren Workflow, den Sie bereits erstellt haben (z. B. eine Zufriedenheitsumfrage oder einen Spezialisten-Routing-Flow). Die Procedure wird nach Abschluss des Workflows nicht fortgesetzt.

Wird eine Procedure-Übergabe als Fin Outcome abgerechnet?

Eine Fin Procedure wird nur dann als Fin Outcome abgerechnet, wenn das Gespräch auf eine von zwei Arten endet:

Resolution – Der Kunde bestätigt, dass Fin sein Problem gelöst hat, oder fragt nach der Antwort von Fin nicht weiter nach.
Procedure Handoff – Fin übergibt über einen konfigurierten Handoff-Schritt oder prozedurenspezifische Guidance an ein Team, einen Teamkollegen oder einen Workflow.
In beiden Fällen werden Ihnen 0,99 $ berechnet – und zwar nur einmal pro Gespräch, unabhängig davon, wie viele Schritte Fin ausgeführt hat oder wie viele Fragen der Kunde gestellt hat.

Hinweis: Es wird keine Gebühr erhoben, wenn eine Procedure nicht abgeschlossen wird, ohne eines dieser Ergebnisse zu erreichen, ein Kunde zu irgendeinem Zeitpunkt um einen Menschen bittet oder das Gespräch durch das Standard-Eskalationsverhalten von Fin oder Workspace-Eskalationsregeln endet.

Für vollständige Details siehe Understanding Fin Outcomes.

Meine Procedure stoppt mitten im Gespräch – könnte es ein Timeout sein?

Ja. Procedures laufen innerhalb eines Let Fin Handle-Blocks in Ihrem Workflow, und dieser Block hat eine standardmäßige Inaktivitäts-Timeout-Einstellung. Wenn ein Kunde länger als diese Zeit zum Antworten braucht, kann der Block schließen, bevor die Procedure abgeschlossen ist. Um das zu beheben, öffnen Sie den Let Fin Handle-Block in Ihren Workflow-Einstellungen und erhöhen Sie das Inaktivitäts-Timeout, um besser zur erwarteten Gesprächsdauer zu passen.

Kann ich Guidance verwenden, um eine Procedure auszulösen?

Nein. Guidance steuert, wie Fin reagiert und sich verhält – es kann keine Procedure starten oder ein Gespräch in eine Procedure leiten. Die beiden Systeme sind getrennt: Guidance formt Fins Ton und Eskalationsregeln; Procedures definieren Schritt-für-Schritt-Workflows, denen Fin folgt, wenn eine bestimmte Absicht erkannt wird.

Um mitten im Gespräch von einer Procedure zu einer anderen zu wechseln, verwenden Sie den @Switch-Befehl innerhalb der Quellprocedure oder aktivieren Sie Agentic Switch in den Procedure-Einstellungen (siehe "4. Help Center content taking priority" in diesem Artikel).

Wenn Sie möchten, dass Fin intelligent entscheidet, wann ein Data connector aufgerufen oder ein bestimmter Ablauf basierend auf dem Gesagten des Kunden ausgeführt wird, bauen Sie diese Logik in eine Procedure ein, nicht in Guidance.

Mein Code-Bedingung verzweigt nicht – wie kann ich sie debuggen?

Code-Bedingungen schlagen still fehl, wenn ein Syntaxfehler vorliegt oder wenn der Datenpfad, auf den Sie zugreifen möchten, im Gesprächskontext nicht existiert. Fin zeigt den Fehler nicht direkt an – es folgt einfach dem Else-Zweig oder bleibt stehen. So diagnostizieren Sie das:

Öffnen Sie das Gespräch im Inbox und aktivieren Sie Show conversation events (siehe "Zugriff auf den Konversations-Debugger" oben).
Überprüfen Sie in Fin's thoughts, welchen Wert Fin als Eingabe für Ihre Bedingung erhalten hat. Wenn der Wert null oder undefined ist, ist der Datenpfad in Ihrem Code falsch.
Überprüfen Sie diese gängigen Datenzugriffsmuster: • E-Mail-Adresse: inputs["user"]["email"] – gibt die E-Mail-Adresse des Kunden zurück, falls verfügbar, sonst None • Connector-Ausgabe: Verwenden Sie den genauen Feldnamen aus dem Antwortschema Ihres Connectors • Gesprächsattribut: inputs["conversation"]["attribute_name"]
Testen Sie Ihren Codeblock in einem Python-Interpreter, bevor Sie ihn in die Procedure einfügen. So werden Syntaxfehler sofort erkannt, ohne ein Live-Gespräch führen zu müssen.
Wenn die Bedingung ausgewertet wird, aber zum falschen Zweig führt, fügen Sie eine print()-Anweisung in Ihren Codeblock ein, um den tatsächlichen Wert zu protokollieren, den Fin erhält. Die Ausgabe erscheint in den Gesprächsereignissen.

Hinweis: Der Kundentyp (user vs. lead) ist derzeit nicht als Procedure-Attribut verfügbar. Wenn Sie nach Kundentyp verzweigen müssen, verwenden Sie stattdessen eine Type-Bedingung in Ihrem Workflow vor dem Fin-Schritt.