Simulationen ermöglichen es Ihnen, Fin Procedures zu validieren, Vertrauen in Ihre Automatisierung aufzubauen und Probleme zu erkennen, bevor sie Ihre users betreffen. Durch die Modellierung vollständiger Gespräche helfen Simulationen Ihrem Team, hochvolumige oder komplexe Szenarien wie Stornierungen und Rückerstattungen sicher zu bewältigen.

Simulationen wurden entwickelt, um zeitaufwändige manuelle Prüfungen zu ersetzen und helfen Ihnen, Probleme oder schrittweise Änderungen im Verhalten von Fin zu erkennen, während sich Ihre Geschäftslogik weiterentwickelt.

Zugriff auf Simulationen

Simulationen befinden sich im Testbereich einer Procedure. So greifen Sie darauf zu:

Öffnen Sie die Procedure, die Sie testen möchten.
Klicken Sie oben rechts auf der Arbeitsfläche auf Test.
Wählen Sie im rechten Bereich die Registerkarte Simulationen aus.

Hinweis: Für den Zugriff auf Simulationen ist die Berechtigung „Can manage workspace data“ erforderlich. Wenn die Schaltfläche Simulationen nicht reagiert, prüfen Sie, ob diese Berechtigung für Ihre Rolle unter Einstellungen > Workspace > Teammates aktiviert ist.

Simulationen umgehen die Intent-Erkennung. Im Gegensatz zu Vorschau oder Live-Gesprächen prüfen Simulationen nicht Ihre Anweisungen „When to use this Procedure“, sondern gehen davon aus, dass die Procedure bereits ausgelöst wurde und führen sie direkt aus. Dadurch sind Simulationen ideal, um die Ausführungslogik isoliert zu testen.

Wichtig:

Vorschau zeigt das vollständige kundenorientierte Erlebnis. Die Nutzung während der Live-Schaltung Ihrer Procedure kann Nachrichten an echte users senden.
Simulationen führen die Procedure im Hintergrund ohne kundenorientierte Ausgabe aus und sind somit die sicherste Methode, um die Logik vor der Live-Schaltung zu validieren. Verwenden Sie Vorschau für schnelle Stichproben; nutzen Sie Simulationen vor jeder Veröffentlichung.

Erstellen einer Simulation

Sie können eine Simulation auf zwei Arten erstellen: mit KI-generierten Vorschlägen für einen schnellen Start oder durch manuelle Definition des Szenarios für volle Kontrolle.

KI-generierte Simulationen: Verwenden Sie diese, um häufige oder erwartete Kundenszenarien basierend auf Ihren Anweisungen schnell abzudecken. Fin AI erstellt „fertige“ Starttests, die Ihnen Zeit sparen.

Manuelle Simulationen: Verwenden Sie diese, wenn Sie präzise Kontrolle über Daten, spezielle Randfälle oder bestimmte Verzweigungen in Ihrer Logik benötigen.

KI-generierte Simulationen

Basierend auf Ihren Anweisungen generiert Fin AI Starttests, die Ihnen helfen, schnell „fertige“ Simulationen zu erstellen.

Öffnen Sie die Registerkarte Simulationen im rechten Bereich Ihrer Procedure.
Überprüfen Sie unter Vorgeschlagen für diese Anweisungen die Liste der vorgeschlagenen Szenarien (z. B. „Vollständige Stornierungsanfrage“).
Klicken Sie auf das Abspiel-Symbol neben einem Vorschlag, um ihn sofort auszuführen.
Sobald eine Simulation erstellt oder aus den Vorschlägen akzeptiert wurde, erscheint sie in Ihrer Liste. Sie können dann auf Alle ausführen klicken, um alle gespeicherten Simulationen gleichzeitig auszuführen.

Manuell erstellte Simulationen

Sie können auch eine Simulation von Grund auf neu erstellen, um spezifische Randfälle basierend auf den Procedure-Anweisungen zu testen.

Klicken Sie im Tab Simulationen auf + Neu.
Simulationsname: Geben Sie Ihrer Simulation einen klaren Titel.
Simulieren als: Wählen Sie einen bestimmten user oder eine Marke, um die Personalisierung zu testen. Sie können aus einer Dropdown-Liste realer users in Ihrem Workspace auswählen.
Eröffnungsnachricht des Kunden: Geben Sie die erste Nachricht ein, die der Kunde sendet (z. B. „Ich brauche Hilfe bei meiner Bestellung“). Sie können auch ein Bild anhängen, z. B. einen Screenshot eines Fehlers, um zu testen, wie Fin visuelle Kontexte verarbeitet.
Zusätzliche Details: Geben Sie Hinweise zur Situation des Kunden oder zu spezifischen Aktionen, die er unternommen hat.

Wählen Sie einen Kanal aus

Simulationen ermöglichen es Ihnen, den Kanal auszuwählen, den Fin für diese Simulation verwendet, damit Sie testen können, wie Fin sich verhält. Verwenden Sie das Dropdown-Menü, um vor der Ausführung Ihrer Simulation zwischen Messenger und Email zu wechseln.

Hinweis: Fin verhält sich je nach Kanal unterschiedlich. Im Email fasst Fin mehrere Informationen in einer einzigen Antwort zusammen, anstatt mehrere Nachrichten zu senden. Anleitung und Content-Targeting können ebenfalls pro Kanal konfiguriert werden – zum Beispiel können Email-Antworten einen formelleren Ton oder eine spezifische Einleitung enthalten.

Verfügbare Daten definieren

Der Abschnitt Customer data available to Fin ermöglicht es Ihnen, die Daten zu definieren, auf die Fin während des Tests zugreifen kann. So stellen Sie sicher, dass Sie mit präzisen Datenwerten testen und nicht auf vage Beschreibungen angewiesen sind.

Simulationszeit: Verwenden Sie dies, um zu definieren, „wann“ das Szenario stattfindet. Die Festlegung eines bestimmten Datums und einer Uhrzeit ermöglicht es Ihnen, zeitkritische Logik zu testen, z. B. ob ein Kunde innerhalb eines 30-tägigen Rückerstattungszeitraums liegt.
Attribute und Daten-Connectoren: Dieser Abschnitt wird mit den Attributen aus Ihrer Procedure vorausgefüllt. Aktualisieren Sie diese Werte (z. B. setzen Sie People.Plan auf „Pro“), um unterschiedliche Verzweigungsergebnisse zu testen.

Hinweis: Um sicherzustellen, dass Ihre Simulation genau läuft, platzieren Sie Daten basierend darauf, wann Fin sie „kennen“ soll:

Attribute verwenden: Wenn Fin die Informationen bereits zu Beginn des Gesprächs kennen soll (z. B. den aktuellen Plan oder das Anmeldedatum des Kunden).
Zusätzliche Details verwenden: Wenn die Informationen vom Kunden während des Gesprächs bereitgestellt werden sollen (z. B. wenn der Kunde seine „Order ID“ in einer Folgeantwort angibt). So können Sie testen, ob Fin diese Daten korrekt erfasst und in einem Attribut speichert.

Hinweis: Daten-Connectoren verwenden in Simulationen keine Live-user-Daten. Anstatt Ihr externes System aufzurufen, verwendet Fin die Testwerte, die Sie im Abschnitt Customer data available to Fin definiert haben. Stellen Sie sicher, dass Sie Ihre Daten-Connector-Felder mit den Werten gefüllt haben, die Fin während des Tests verwenden soll – andernfalls liefert der Connector keine Ergebnisse.

Fin-Verhalten bewerten

Definieren Sie die Kriterien, die erfüllt sein müssen, damit der Test besteht. Klicken Sie auf + Kriterien hinzufügen und wählen Sie:

Fin-Antwort: Geben Sie an, was Fin während des Gesprächs sagen soll (oder nicht sagen soll).
Attribute: Überprüfen Sie, ob ein Attribut gesetzt, nicht gesetzt, gleich oder ungleich einem bestimmten Wert war.
Daten-Connector: Überprüfen Sie, ob ein Connector ausgelöst, nicht ausgelöst oder genau X-mal ausgelöst wurde.
Ergebnis der Anweisung: Prüfen Sie, ob das Gespräch zu einem bestimmten Abschluss kam, z. B. Beendigung, Übergabe an einen Kollegen oder andere Ergebnisse wie der Wechsel zu einer anderen Procedure.

Nach der Konfiguration klicken Sie auf Speichern.

Hinweis: Wenn Sie auf Speichern klicken, verwendet Fin KI, um Ihr Simulationsformular zu überprüfen. Wenn die Anweisungen unklar sind oder die Erfolgskriterien inkonsistent sind, erhalten Sie Empfehlungen zur Verbesserung des Tests für genauere Ergebnisse.

Best Practices für Simulationsabdeckung

Um das Beste aus Simulationen herauszuholen, strukturieren Sie Ihre Testsuite nach diesen Prinzipien:

Testen Sie einen Zweig pro Simulation. Wenn Ihr Procedure Bedingungen oder Unterverfahren mit mehreren Pfaden hat, erstellen Sie für jeden Zweig eine separate Simulation. Dies baut ein Regression-Sicherheitsnetz auf – wenn eine zukünftige Änderung einen bestimmten Pfad unterbricht, erkennen Sie es sofort.
Decken Sie sowohl Erfolgs- als auch Fehlerpfade für Data Connectors ab. Führen Sie eine Simulation durch, bei der Ihr Connector gültige Daten zurückgibt, und eine weitere, bei der er nichts zurückgibt oder fehlschlägt. Dies überprüft, dass Ihre Fallback-Logik (z. B. ein @Condition-Schritt, der eine leere Antwort behandelt) korrekt funktioniert.
Führen Sie alle Simulationen vor der Veröffentlichung von Änderungen aus. Klicken Sie nach der Bearbeitung eines Procedure auf Alle ausführen, um Ihre gesamte Suite erneut auszuführen, bevor Sie live gehen. Jede Simulation, die neu fehlschlägt, signalisiert eine durch Ihre Änderung eingeführte Regression.
Verwenden Sie beschreibende Simulationsnamen. Benennen Sie jede Simulation nach dem Szenario, das sie darstellt (z. B. „Volle Rückerstattung – innerhalb von 30 Tagen“ oder „Stornierung – keine Bestellung gefunden“). So können Sie beim Überprüfen der Ergebnisse leicht erkennen, welcher Test welchen Pfad abdeckt.

Teststrategie: Happy Path, Risk Path und Edge Cases

Eine ausgewogene Simulationssuite deckt drei Szenariotypen ab. Zusammen geben sie Ihnen die Sicherheit, dass Ihr Procedure unter normalen Bedingungen korrekt funktioniert, Fehler elegant behandelt und nicht zusammenbricht, wenn Kunden sich unerwartet verhalten.

Happy Path
Der Happy Path repräsentiert den idealen, ununterbrochenen Ablauf – ein Kunde, der genau die richtigen Informationen liefert und alle Bedingungen erfüllt, damit Fin das Procedure erfolgreich abschließen kann. Beginnen Sie immer hier. Wenn der Happy Path fehlschlägt, wird das Debuggen komplexerer Pfade deutlich schwieriger.
Beispiel: Ein Kunde beantragt eine Rückerstattung innerhalb des 30-Tage-Fensters, hat eine gültige Bestell-ID, und der Data Connector liefert seine Bestelldetails. Fin verarbeitet die Rückerstattung und bestätigt sie in einem Durchgang.
Risk Path
Risk Paths testen die Szenarien, die in der Produktion am wahrscheinlichsten schiefgehen – typischerweise wenn externe Daten fehlen, Bedingungen nicht erfüllt sind oder ein Fallback-Zweig ausgelöst werden muss. Diese Tests schützen Ihre Kunden davor, falsche oder unvollständige Antworten zu erhalten.
Beispiele: Der Data Connector liefert keine Bestellung (testen Sie, dass Fin den Kunden nach seiner Bestell-ID fragt). Der Kunde befindet sich außerhalb des Rückerstattungszeitraums (testen Sie, dass Fin die korrekte Richtlinie kommuniziert und die richtige Übergabe anbietet). Ein Attribut ist leer, wenn ein Condition-Schritt es auswertet (testen Sie, dass Fins Fallback-Pfad korrekt ausgelöst wird).
Edge Cases
Edge Cases decken ungewöhnliche oder Grenzfall-Eingaben ab, die technisch gültig, aber selten sind. Diese Tests sind besonders wichtig für Procedures mit zeitkritischer Logik, numerischen Schwellenwerten oder Freitext-Kundeneingaben.
Beispiele: Ein Kunde beantragt eine Rückerstattung genau am Tag 30 (der Grenzwert des Fensters). Ein Kunde sendet eine mehrdeutige Eröffnungsnachricht, die mehrere Intents treffen könnte. Ein Kunde gibt seine Bestell-ID in einem unerwarteten Format an oder fügt zusätzlichen Text hinzu.

Tipp: Verwenden Sie beschreibende Simulationsnamen, um anzuzeigen, zu welcher Kategorie jeder Test gehört – zum Beispiel „Rückerstattung – Happy Path“, „Rückerstattung – keine Bestellung gefunden (Risk)“ oder „Rückerstattung – Grenztag 30 (Edge)“. So lassen sich Lücken in Ihrer Abdeckung auf einen Blick erkennen.

Ausführen und Überprüfen von Ergebnissen

Sobald Sie einen Test ausführen, erscheint er im Tests-Panel auf der rechten Seite mit einem Statusindikator:

Wird ausgeführt: Der Test wird gerade aktiv ausgeführt.
Bestanden: Der Test wurde ausgeführt und erfüllte alle definierten Erfolgskriterien erfolgreich.
Fehlgeschlagen: Der Test wurde ausgeführt, erfüllte aber nicht die definierten Erfolgskriterien.
In Warteschlange: Der Test wurde gestartet, wartet aber darauf, dass die vorherige Simulation abgeschlossen ist, bevor er ausgeführt wird.

Um ein Ergebnis zu untersuchen, klicken Sie auf Konversation anzeigen. Dies öffnet das vollständige Gesprächsprotokoll zwischen dem simulierten Kunden und Fin, sodass Sie genau sehen können, wie der Ablauf verlief und warum ein Test bestanden oder fehlgeschlagen ist.

Debugging einer fehlgeschlagenen Simulation

Wenn eine Simulation als Fehlgeschlagen markiert ist, enthält das über Konversation anzeigen verfügbare Protokoll alles, was Sie benötigen, um die Ursache zu identifizieren. So lesen Sie es effektiv:

Fins Gedanken
Erweitern Sie in jedem Schritt des Gesprächs Fins Überlegungen, um zu sehen, wie es die Nachricht des Kunden interpretiert hat, welchen Procedure-Schritt es ausführte und welche Entscheidung es traf. Wenn Fin einen unerwarteten Pfad eingeschlagen hat, zeigen Fins Gedanken normalerweise genau, wo seine Interpretation von Ihrer Absicht abwich. Achten Sie auf Schritte, bei denen Fins Interpretation eines Attributs oder einer Bedingung nicht mit Ihren Erwartungen übereinstimmt.
Konversationsereignisse
Konversationsereignisse erscheinen inline im Protokoll und zeigen Aktionen auf niedriger Ebene wie Attributaktualisierungen, Data Connector-Aufrufe und Übergabeauslöser. Verwenden Sie diese, um zu überprüfen, dass die richtigen Connectoren zur richtigen Zeit ausgelöst wurden und dass Attribute vor jedem Verzweigungsschritt die erwarteten Werte hatten.
Fehler eingrenzen
Vergleichen Sie, was Sie in Fins Gedanken und Konversationsereignissen sehen, mit Ihren definierten Erfolgskriterien. Ein häufiges Muster ist, dass ein Condition-Schritt zum falschen Zweig auswertet – typischerweise weil ein Attribut leer war oder einen unerwarteten Wert hatte. Überprüfen Sie Ihre Customer data available to Fin-Einstellungen, um sicherzustellen, dass alle erforderlichen Attribute vor der Simulation ausgefüllt waren.

Tipp: Nachdem Sie die Ursache identifiziert haben, passen Sie Ihr Procedure oder die Simulationseinstellungen an und klicken Sie auf Ausführen bei derselben Simulation, um sofort erneut zu testen. Sie müssen keine neue Simulation erstellen – die bestehende behält ihre Konfiguration.

Simulationsnutzungsgrenzen

Es gibt eine Begrenzung für die Anzahl der Simulationen, die Sie jeden Monat ausführen können. Diese Begrenzung wird auf Workspace-Ebene angewendet und am ersten Tag jedes Kalendermonats zurückgesetzt.

Jeder Workspace erhält eine monatliche Zuteilung von Simulationsläufen. Die Zuteilung basiert auf dem Gesprächsvolumen-Segment Ihres Workspaces, wobei größere Kunden höhere Zuteilungen erhalten.

Die Simulationszuteilung basiert auf dem Gesprächsvolumen Ihres Workspaces in Intercom.

Wir ordnen Ihren Workspace einem Segment zu, basierend auf der Anzahl der Gespräche im letzten Kalendermonat.
Ihr Segment wird monatlich neu bewertet und Ihre Zuteilung spiegelt das Gesprächsvolumen des letzten Monats wider.
Wenn Ihr Gesprächsvolumen steigt oder sinkt, kann sich Ihre Simulationszuteilung im nächsten Monatszyklus ändern.

Gesprächsvolumen-Segment	Simulationslimit pro Monat
Unter 1K	50
1K–15K	200
15K–100K	350
100K–1M	1000
1M+	2500

Überwachung Ihrer Nutzung

Um Ihnen bei der Verwaltung Ihrer Tests zu helfen, bietet Fin visuelle Indikatoren im Tab Simulationen:

Nutzungswarnung

Wenn Ihr Arbeitsbereich 80 % seines monatlichen Limits erreicht, erscheint ein gelbes Warnbanner. Es zeigt Ihre aktuelle Nutzung an (z. B. „85/100“) und erinnert Sie daran, wann das Limit zurückgesetzt wird.

Limit erreicht

Sobald Sie 100 % Ihres monatlichen Limits erreicht haben, erscheint eine rote Fehlermeldung. Sie können keine weiteren Simulationen ausführen, bis der nächste Monat beginnt.

Hinweis: Wenn Sie Ihr Limit erreichen, können Sie weiterhin vorherige Simulationsergebnisse und Transkripte durch Klicken auf „Konversation ansehen“ überprüfen, aber die Schaltflächen „Ausführen“ und „Alle ausführen“ werden deaktiviert sein.

FAQs

Interagieren Simulationen mit meinen Live-APIs oder externen Daten?

Nein. Im Gegensatz zum Vorschau-Tool greifen Simulationen nicht auf tatsächliche APIs oder externe Systeme (wie Shopify oder Stripe) zu. Es ist nicht möglich, während einer Simulation Daten in einer externen API zu lesen oder zu ändern. So können Sie die Logik sicher testen, ohne reale Daten zu beeinflussen.

Warum Simulationen statt manueller Tests verwenden?

Simulationen ermöglichen es Ihnen, Procedures im großen Maßstab zu validieren und sicherzustellen, dass Fin in komplexen, risikoreichen Szenarien zuverlässig funktioniert – im Gegensatz zu manuellen Tests, die sich besser für schnelle Stichproben oder Konfigurationsüberprüfungen eignen. Simulationen vor jedem Start helfen Ihnen, unerwartetes Verhalten frühzeitig zu erkennen.

Was passiert, wenn eine Simulation fehlschlägt?

Eine fehlgeschlagene Simulation kann vollständig überprüft werden – öffnen Sie die simulierte Konversation, um zu verstehen, warum Fin nicht wie erwartet reagiert hat, passen Sie Ihre Procedure an und führen Sie die Simulation erneut durch, ohne Kunden zu beeinträchtigen.

Warum ist meine Simulation als „Fehlgeschlagen“ markiert, obwohl Fin das Problem erfolgreich gelöst hat?

Eine Simulation, die als „Fehlgeschlagen“ markiert ist, obwohl Fin das Problem gelöst hat, bedeutet meist, dass Ihre Erfolgskriterien zu streng sind. Wenn Sie beispielsweise verlangen, dass Fin „nach einer Bestell-ID fragt“, Fin aber schlau genug ist, die ID automatisch zu finden, schlägt der Test fehl, weil Fin die Frage übersprungen hat. Aktualisieren Sie Ihre Kriterien, um sich auf das Endergebnis (z. B. „Procedure abgeschlossen“) zu konzentrieren, anstatt bestimmte Zwischenschritte vorzuschreiben.

Fin stoppt mitten in der Simulation. Warum bleibt es hängen?

Fin stoppt oft, wenn es in Ihren Anweisungen auf eine „Sackgasse“ stößt, z. B. wenn eine Variable leer ist (z. B. People.signed_up). Wenn Sie Fin nicht gesagt haben, was bei fehlenden Daten zu tun ist, stoppt es. Stellen Sie sicher, dass Ihre Anweisungen einen „Fallback“-Plan enthalten, z. B.: „Prüfen Sie, ob die Variable einen Wert hat. Wenn sie leer ist, fragen Sie den Kunden nach dem Datum.“

Wo soll ich Testdaten wie „Anmeldedaten“ oder „Bestellhistorie“ eingeben?

Testdaten wie Anmeldedaten oder Bestellhistorie sollten im Abschnitt Kundendaten, die Fin zur Verfügung stehen, der Simulationseinstellungen eingegeben werden – nicht in der Eröffnungsnachricht des Kunden oder den zusätzlichen Details, da Fin diese möglicherweise übersieht. Geben Sie genaue Werte (z. B. 2024-06-01) in die spezifischen Attribute oder Variablen ein, die Sie testen.

Mein Tool funktioniert im echten Leben, aber in der Simulation nicht. Warum?

Simulationen holen keine echten Daten aus externen Systemen, daher liefert Ihr Data Connector in der Simulation keine Live-Ergebnisse wie im echten Gespräch. Wenn Ihr Connector in Live-Gesprächen funktioniert, aber in der Simulation fehlschlägt, liegt das wahrscheinlich daran, dass die erwarteten Rückgabewerte im Abschnitt Customer data available to Fin nicht definiert sind. Fügen Sie dort die Daten hinzu, die Ihr Connector normalerweise zurückgeben würde, und führen Sie die Simulation erneut aus.

Werden Simulationen separat von Procedures abgerechnet?

Simulationen sind in Procedures enthalten und werden nicht als separate Position berechnet. Für das Ausführen von Simulationen entstehen keine zusätzlichen Kosten.

Warum sollte ich meine Procedure per E-Mail testen?

Das Testen Ihrer Procedure per E-Mail validiert kanal-spezifisches Verhalten, das sich vom Messenger unterscheidet. In E-Mails fasst Fin mehrere Informationen in einer einzigen E-Mail zusammen, anstatt mehrere Nachrichten zu senden. Anleitungen und Inhalte können auch auf bestimmte Kanäle zugeschnitten werden – zum Beispiel können E-Mail-Antworten formeller sein oder eine spezielle Einleitung enthalten. Das Simulieren von E-Mail-Gesprächen ermöglicht es Ihnen, dieses Verhalten zu validieren und mit Vertrauen auf E-Mail zu setzen.

Warum gibt es eine Begrenzung für Simulationsläufe?

Jeder Simulationslauf benötigt Ressourcen, um genaue KI-Vorhersagen zu erzeugen. Wir stellen ein monatliches Kontingent bereit, damit Sie Ihre Procedures für Standardanwendungen frei testen können und extreme Nutzung keine unkontrollierten Kosten verursacht.

Kann ich eine Unter-Prozedur unabhängig simulieren?

Nein. Unter-Prozeduren haben kein eigenes Simulationsfenster und können nicht isoliert ausgeführt werden. Um eine Unter-Prozedur zu testen, führen Sie eine Simulation der übergeordneten Procedure durch und konfigurieren das Szenario so, dass der Ausführungspfad die Unter-Prozedur erreicht – indem Sie die Kunden-Nachricht, Attribute und zusätzliche Details so einstellen, dass der spezifische Zweig, der sie aufruft, ausgelöst wird.

Wenn Sie mehrere Unter-Prozeduren innerhalb derselben übergeordneten Procedure haben, erstellen Sie für jede eine separate Simulation, wobei jede Simulation das Szenario abdeckt, das zum Aufruf dieser Unter-Prozedur führt.

Mein Data Connector liefert in der Simulation leere Ergebnisse. Was soll ich tun?

Leere Data Connector-Ergebnisse in einer Simulation werden meist durch fehlende Testdaten verursacht. Simulationen holen keine Live-Daten aus externen Systemen – Sie müssen die Werte, die Ihr Data Connector zurückgeben soll, im Abschnitt Customer data available to Fin der Simulationseinstellungen definieren. Prüfen Sie, ob Sie die relevanten Data Connector-Felder mit den Testwerten gefüllt haben, die Fin verwenden soll.

Wenn Sie absichtlich den Pfad „Connector gibt nichts zurück“ testen, ist dies erwartetes Verhalten – und genau das, was Sie testen sollten. Stellen Sie sicher, dass Ihre Procedure einen Fallback-@Condition-Schritt hat, der leere Connector-Antworten behandelt:

Wenn der Connector auch bei einem Nutzer mit echten Daten leer zurückgibt, prüfen Sie, ob Ihr Testkontakt eine gültige external_id hat, die mit der Kundenkennung Ihres externen Systems übereinstimmt.

Verwandte Artikel

Wie man Fin Tasks einrichtet

Fin Procedures erklärt

Übergang von Fin Tasks zu Procedures

Simulationen vs. Batch-Tests vs. Previews

Wie man intern für Fin Procedures eintritt

Simulationen für Fin Procedures durchführen