Simulations allow you to validate Fin Procedures, build confidence in your automation, and catch problems before they impact your customers. By modeling full conversations, simulations help your team handle high-volume or complex scenarios, such as cancellations and refunds, with certainty.

Designed to replace time-consuming manual checks, simulations help you identify issues or gradual changes in Fin's behavior as your business logic evolves.

Accessing simulations

Simulations are located within the testing panel of a Procedure. To access them:

Open the Procedure you wish to test.
Click Test in the top right corner of the canvas.
Select the Simulations tab in the right-hand panel

Note: Accessing Simulations requires the following permissions:

"Can manage workspace data",
"Can access lead and user profile pages" and
"Can access lists of people, companies, and accounts".

If the Simulations button isn't responding, check with your workspace admin that these permissions are enabled for you in Settings > Workspace > Teammates.

Simulations bypass intent matching. Unlike Preview or live conversations, simulations don't check your 'When to use this Procedure' instructions, they assume the Procedure has already been triggered and run it directly. This makes simulations ideal for testing execution logic in isolation.

Important:

Preview shows the full customer-facing experience, using it while your procedure is live can expose messages to real customers.
Simulations run the procedure in the background with no customer-facing output, making them the safest way to validate logic before going live. Use Preview for quick spot checks; use Simulations before every publish.

Creating a simulation

You can create a simulation in two ways: using AI-generated suggestions for a quick start, or manually defining the scenario for full control.

AI-generated simulations: Use these to quickly cover common or expected customer scenarios based on your instructions. Fin AI generates "ready-made" starter tests to save you time.

Manual simulations: Use these when you need precise control over data, specific edge cases, or particular branches in your logic.

AI-generated simulations

Based on your instructions, Fin AI will generate starter tests to help you quickly create "ready-made" simulations.

Open the Simulations tab in the right-hand panel of your Procedure.
Under Suggested for these instructions, review the list of proposed scenarios (e.g., "Full cancellation request").
Click the Play icon next to a suggestion to run it instantly.
Once a simulation is created or accepted from the suggestions, it will appear in your list. You can then click Run all to execute all of your saved simulations at once.

Manually created simulations

You can also build a simulation from scratch to test specific edge cases based on the Procedure instructions.

In the Simulations tab, click + New.
Simulation name: Give your simulation a clear title.
Simulate as: Choose a specific user or brand to test personalization. You can select from a dropdown list of real users in your workspace.
Customer's opening message: Enter the first message the customer sends (e.g., "I need help with my order"). You can also attach an image, such as a screenshot of an error, to test how Fin handles visual context.
Additional details: Provide guidance regarding the customer's situation or specific actions they have taken.

Select a channel

Simulations allow you to select the channel Fin will use for this simulation, so you can test how Fin behaves. Use the channel dropdown to switch between Messenger and Email before running your simulation.

Note: Fin behaves differently depending on the channel. In Email, Fin aggregates multiple pieces of information into a single response rather than sending several messages. Guidance and Content targeting can also be configured per channel - for example, Email responses can be set to use a more formal tone or include a specific introduction.

Define available data

The Customer data available to Fin section allows you to define the data Fin has access to during the test. This ensures you are testing against precise data values rather than relying on vague descriptions.

Simulation time: Use this to define "when" the scenario is happening. Setting a specific date and time allows you to test time-sensitive logic, such as checking if a customer is within a 30-day refund window.
Attributes and Data Connectors: This section pre-populates with the attributes referenced in your Procedure. Update these values (e.g., set People.Plan to "Pro") to test different branching outcomes.

Note: To ensure your simulation runs accurately, place data based on when Fin should "know" it:

Use Attributes: If Fin is supposed to already know the information at the start of the conversation (e.g., the customer's current Plan or Sign-up date).
Use Additional details: If the information is meant to be provided by the customer during the conversation (e.g., the customer provides their "Order ID" in a follow-up response). This allows you to test if Fin correctly captures and stores that data in an attribute.

Note:

Data Connectors don't use live user data in simulations. Instead of calling your external system, Fin uses the test values you define in the Customer data available to Fin section. Make sure you've populated your Data Connector fields with the values you want Fin to use during the test — otherwise the connector will return empty results.
The Customer data available to Fin section only shows and retains attributes that are explicitly referenced in your Procedure's instructions or a code block. If you manually add an attribute using the + Add attribute button but that attribute isn't referenced anywhere in the Procedure, the system will not save it — it disappears after you save because it has no effect on the simulation. To add a custom value that persists, make sure the attribute is first used in the Procedure itself.

Evaluate Fin's behavior

Define the criteria that must be true for the test to pass. Click + Add criteria and select:

Fin reply: Geben Sie an, was Fin während des Gesprächs sagen darf (oder nicht).
Attributes: Überprüfen Sie, ob ein Attribut gesetzt wurde, nicht gesetzt wurde, gleich war oder nicht gleich war zu einem bestimmten Wert.
Data connector: Überprüfen Sie, ob ein Connector ausgelöst wurde, nicht ausgelöst wurde oder genau X Mal ausgelöst wurde.
Instruction outcome: Prüfen Sie, ob das Gespräch ein bestimmtes Ergebnis erreicht hat, wie z. B. abgeschlossen, an einen Kollegen übergeben oder andere Ergebnisse wie das Wechseln zu einer anderen Procedure.

Once configured, click Save.

Note: When you click Save, Fin uses AI to review your simulation form. If the instructions are unclear or if the success criteria are inconsistent, you will see recommendations on how to improve the test for more accurate results.

Best practices for simulation coverage

Um das Beste aus Simulationen herauszuholen, strukturieren Sie Ihre Testsuite um diese Grundsätze:

Test one branch per simulation. Wenn Ihre Procedure Bedingungen oder Unterprozeduren mit mehreren Pfaden hat, erstellen Sie für jeden Zweig eine eigene Simulation. So entsteht ein Regression-Sicherheitsnetz – wenn eine zukünftige Änderung einen bestimmten Pfad unterbricht, erkennen Sie es sofort.
Cover both success and failure paths for Data Connectors. Führen Sie eine Simulation aus, bei der Ihr Connector gültige Daten zurückgibt, und eine weitere, bei der er nichts zurückgibt oder fehlschlägt. So wird überprüft, dass Ihre Fallback-Logik (z. B. ein @Condition-Schritt, der eine leere Antwort behandelt) korrekt funktioniert.
Run all simulations before publishing changes. Nachdem Sie eine Procedure bearbeitet haben, klicken Sie auf Run all, 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.
Use descriptive simulation names. Benennen Sie jede Simulation nach dem Szenario, das sie darstellt (z. B. „Full refund — within 30 days" oder „Cancellation — no order found"). So erkennen Sie beim Überprüfen der Ergebnisse leicht, welcher Test welchen Pfad abdeckt.

Testing strategy: happy path, risk path, and edge cases

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

Happy path
Der Happy Path stellt den idealen, ungestörten Ablauf dar – ein Kunde, der genau die richtigen Informationen liefert und alle Bedingungen erfüllt, damit Fin die Procedure erfolgreich abschließen kann. Beginnen Sie immer hier. Wenn der Happy Path fehlschlägt, wird die Fehlersuche in komplexeren Pfaden viel schwieriger.
Example: Ein Kunde fordert eine Rückerstattung innerhalb des 30-Tage-Fensters an, hat eine gültige Bestell-ID und der Data Connector liefert seine Bestelldaten. Fin verarbeitet die Rückerstattung und bestätigt sie in einem einzigen Durchgang.
Risk path
Risk Paths testen Szenarien, die in der Produktion am wahrscheinlichsten schiefgehen – typischerweise dort, wo externe Daten fehlen, Bedingungen nicht erfüllt sind oder ein Fallback-Zweig greifen muss. Diese Tests schützen Ihre Kunden davor, falsche oder unvollständige Antworten zu erhalten.
Examples: The Data Connector returns no order (test that Fin asks the customer for their order ID). The customer is outside the refund window (test that Fin communicates the correct policy and offers the right handoff). An attribute is empty when a Condition step evaluates it (test that Fin's fallback path triggers correctly).
Edge cases
Edge cases cover unusual or boundary-condition inputs that are technically valid but uncommon. These tests are especially important for Procedures with time-sensitive logic, numeric thresholds, or free-text customer inputs.
Examples: A customer requests a refund exactly on day 30 (the boundary of the window). A customer sends an ambiguous opening message that could match multiple intents. A customer provides their order ID in an unexpected format or includes extra text alongside it.

Tip: Use descriptive simulation names to signal which category each test belongs to — for example, „Refund — happy path", „Refund — no order found (risk)", or „Refund — boundary day 30 (edge)". This makes it easier to spot gaps in your coverage at a glance.

Running and reviewing results

Once you run a test, it appears in the Tests panel on the right-hand side with a status indicator:

Running: The test is actively being executed.
Passed: The test ran and successfully met all defined success criteria.
Failed: The test ran but did not meet the defined success criteria.
Queued: The test has been initiated but is waiting for the preceding simulation to finish before executing.

To investigate a result, click See conversation. This opens the full back-and-forth transcript between the simulated customer and Fin, making it easy to see exactly how the flow played out and why a test passed or failed.

Debugging a failed Simulation

When a simulation is marked Failed, the transcript available via See conversation contains everything you need to identify the root cause. Here's how to read it effectively:

Fin's thoughts
At each step of the conversation, expand Fin's reasoning to see how it interpreted the customer's message, which Procedure step it was executing, and what decision it made. If Fin took an unexpected path, Fin's thoughts will usually show you exactly where its interpretation diverged from your intention. Look for steps where Fin's interpretation of an attribute or condition doesn't match what you expected.
Conversation events
Conversation events appear inline in the transcript and show low-level actions such as attribute updates, Data Connector calls, and handoff triggers. Use these to verify that the right connectors fired at the right time and that attributes were set to the expected values before each branching step.
Pinpointing the failure
Cross-reference what you see in Fin's thoughts and conversation events against your defined success criteria. A common pattern is a Condition step evaluating to the wrong branch — typically because an attribute was empty or had an unexpected value. Check your Customer data available to Fin setup to ensure all required attributes were populated before the simulation ran.

Tip: After identifying the cause, adjust your Procedure or simulation setup and click Run on the same simulation to re-test immediately. You don't need to create a new simulation — the existing one retains its configuration.

Simulation usage limits

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

Jeder Workspace erhält eine monatliche Zuteilung von Simulationsläufen. Die Zuteilung basiert auf dem Gesprächsvolumensegment Ihres Workspaces; bei größeren Kunden ist die Zuteilung höher.

Simulation allowance is based on your workspace’s conversation volume in Intercom.

We assign your workspace to a segment using the number of conversations in the last calendar month.
Your segment is re-evaluated monthly and your allowance will reflect your most recent month’s conversation volume.
If your conversation volume increases or decreases, your Simulation allowance may change in the next monthly cycle.

Conversation Volume Segment	Simulation Limit per month
Under 1K	250
1K–15K	1.000
15K–100K	1.750
100K–1M	5.000
1M+	12.500

Überwachung Ihrer Nutzung

Um Ihnen bei der Verwaltung Ihrer Tests zu helfen, bietet Fin innerhalb des Tabs „Simulations" visuelle Hinweise:

Nutzungswarnung

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

Limit erreicht

Sobald Sie 100 % Ihres Monatslimits erreicht haben, erscheint eine rote Fehlermeldung. Sie können bis zum Beginn des nächsten Monats keine weiteren Simulationen durchführen.

Hinweis: Wenn Sie Ihr Limit erreicht haben, können Sie frühere Simulationsergebnisse und Transkripte weiterhin durch Klicken auf "Konversation anzeigen" einsehen, aber die Schaltflächen "Ausführen" und "Alle ausführen" sind deaktiviert.

FAQs

Interagieren Simulationen mit meinen Live-APIs oder externen Daten?

Nein. Im Gegensatz zum Preview-Tool rufen Simulationen keine echten APIs oder externen Systeme (wie Shopify oder Stripe) auf. Es ist nicht möglich, während einer Simulation aus einer externen API zu lesen oder Daten zu ändern. So können Sie die Logik sicher testen, ohne reale Daten zu beeinträchtigen.

Warum Simulations statt manueller Tests verwenden?

Simulationen ermöglichen es Ihnen, Procedures in großem Maßstab zu validieren und sicherzustellen, dass Fin in komplexen, risikoreichen Szenarien zuverlässig arbeitet – im Gegensatz zu manuellen Tests, die sich am besten für schnelle Stichproben oder Konfigurationsüberprüfungen eignen. Das Ausführen von Simulationen vor jedem Release hilft 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 ohne Auswirkungen auf Kunden durch.

Warum ist meine Simulation mit "Failed" markiert, obwohl Fin das Problem gelöst hat?

Eine Simulation, die mit "Failed" markiert ist, obwohl Fin das Problem gelöst hat, bedeutet normalerweise, dass Ihre Erfolgskriterien zu strikt sind. Wenn Sie beispielsweise verlangen, dass Fin "nach einer Bestell-ID fragt", Fin die ID aber automatisch findet, wird der Test fehlschlagen, 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 bleibt mitten in der Simulation stehen. Warum bleibt es hängen?

Fin bleibt oft stehen, 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 zu tun ist, wenn Daten fehlen, 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 Simulationskonfiguration eingegeben werden – nicht in der Eröffnungsnachricht des Kunden oder den Feldern Zusätzliche Details, da Fin sie übersehen könnte. 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, schlägt aber in der Simulation fehl. Warum?

Simulationen rufen keine echten Daten aus externen Systemen ab, sodass Ihr Data Connector in der Simulation nicht die gleichen Live-Ergebnisse liefert wie in einer realen Konversation. Wenn Ihr Connector in Live-Gesprächen funktioniert, in der Simulation aber fehlschlägt, liegt dies wahrscheinlich daran, dass die erwarteten Rückgabewerte nicht im Abschnitt Kundendaten, die Fin zur Verfügung stehen definiert wurden. 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 separater Posten berechnet. Für das Ausführen von Simulationen entstehen Ihnen 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. Guidance und Content können auch auf bestimmte Kanäle zugeschnitten werden – zum Beispiel können E-Mail-Antworten formeller formuliert oder mit einer speziellen Einleitung versehen werden. Das Simulieren von E-Mail-Konversationen ermöglicht es Ihnen, dieses Verhalten zu validieren und mit Vertrauen in den E-Mail-Betrieb zu gehen.

Warum gibt es ein Limit für Simulationsläufe?

Jeder Simulationslauf erfordert Ressourcen, um genaue KI-Vorhersagen zu erzeugen. Wir stellen ein monatliches Kontingent zur Verfügung, damit Sie Ihre Procedures für Standardanwendungen frei testen können, während extreme Nutzung verhindert wird, die zu unkontrollierten Kosten führen könnte.

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 für die übergeordnete Procedure aus und konfigurieren Sie das Szenario so, dass der Ausführungspfad die Unter-Prozedur erreicht – legen Sie die Kundenmeldung, Attribute und zusätzlichen Details so fest, dass der Zweig ausgelöst wird, der sie aufruft.

Wenn Sie mehrere Unter-Prozeduren innerhalb desselben übergeordneten Elements haben, erstellen Sie für jede eine separate Simulation, wobei jede Simulation das Szenario abdeckt, das dazu führt, dass diese Unter-Prozedur aufgerufen wird.

Mein Data Connector gibt in der Simulation leere Ergebnisse zurück. Was soll ich tun?

Leere Data-Connector-Ergebnisse in einer Simulation werden normalerweise durch fehlende Testdaten verursacht. Simulationen rufen keine Live-Daten aus externen Systemen ab – Sie müssen die Werte definieren, die Ihr Data Connector in den Abschnitt "Kundendaten, die Fin zur Verfügung stehen" der Simulationskonfiguration zurückgeben soll. Überprüfen Sie, ob Sie die relevanten Data-Connector-Felder mit den Testwerten gefüllt haben, die Sie möchten, dass Fin verwendet.

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 enthält, der leere Connector-Antworten behandelt:

Wenn der Connector auch für einen 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.

Wie viele Simulationen kann ich pro Monat durchführen?

Ihr monatliches Simulationskontingent hängt vom Gesprächsvolumen Ihres Workspaces in Intercom im Vormonat ab. Das Limit gilt auf Workspace-Ebene und wird am ersten Tag jedes Monats zurückgesetzt:

Segment des Gesprächsvolumens	Simulationslimit pro Monat
Unter 1K	250
1K–15K	1.000
15K–100K	1.750
100K–1M	5.000
1M+	12.500

Wann wird mein Simulationslimit zurückgesetzt?

Dein Simulationskontingent wird am ersten Tag jedes Kalendermonats zurückgesetzt, unabhängig davon, wann du beigetreten bist oder wie viele Simulationen du durchgeführt hast. Unbenutzte Durchläufe werden nicht übertragen — dein Kontingent beginnt jeden Monat neu.

Kann ich mein Simulationslimit erhöhen?

Simulationslimits werden automatisch anhand des Gesprächsvolumens deines Workspaces festgelegt und zu Beginn jedes Kalendermonats neu bewertet. Wenn dein Gesprächsvolumen steigt, erhöht sich dein Kontingent im nächsten Monatszyklus — es gibt keine Möglichkeit, zusätzliche Durchläufe manuell zu kaufen oder dein Limit außerhalb dieses Stufensystems zu erhöhen. Wenn du dein monatliches Limit vor dem Rücksetzdatum erreichst, kannst du weiterhin frühere Simulationsergebnisse und Transkripte überprüfen, aber die Schaltflächen "Run" und "Run all" sind deaktiviert, bis dein Kontingent zurückgesetzt wird.

Verwandte Artikel

Run Simulations for Fin Procedures