Skip to main content

Testing

Test Runs (under Workflows) let you test your AI workflows automatically and repeatably — much like writing automated tests for code. Configure a test once, then re-run it whenever you change a flow to make sure existing journeys still work.

This builds on the manual Test flow feature: instead of typing each message yourself, you describe the conversation and Flowcall runs it against the AI for you.

Configuring a Test​

A test defines how a simulated conversation should run:

SettingWhat it controls
Conversation instructionsHow the simulated customer should talk to the AI (for example, "provide your order ID, then ask where it is").
Phone numberThe identity the test conversation runs as.
Max turnsAfter how many back-and-forth turns the test stops.
Completion prompt (optional)When the conversation should stop — e.g. the AI is repeating itself, or it handed off to a human. If omitted, the test still stops at max turns or when the conversation appears stuck.
Assertion promptDefines whether the test passed or failed, based on what happened in the conversation.

The assertion prompt is what makes this a real test: you set expectations, then re-run the test regularly to confirm the system still meets them. If you change a flow, re-run your tests to make sure older journeys didn't break.

Variables​

Add payload variables so the same test can run against different customer inputs. For example, set an order ID for one run and a different order ID for the next run, without rewriting the test. Payload values are available to the simulated customer, so use them for information the customer knows or can provide.

Mocking (Active Mapping)​

Much of a conversation depends on data coming from APIs — and that data changes. A "delayed order" might be delayed today but delivered tomorrow, which would make the test fail for the wrong reason.

Active mapping solves this by letting you mock the values of data points used in a flow. When the test runs, the mocked value is used instead of making a real API call. This:

  • Makes tests evergreen — they don't break when real-world data changes.
  • Isolates the test from external systems and APIs.

This is the same principle as mocking in code-level tests.

Payload and objective mocks are not interchangeable: payload describes customer-known facts, while objective mocks control values returned by workflow data points or actions. Assertions and completion prompts should match the selected values.

Child-Ticket Handoffs​

When a workflow needs a human-agent child ticket to supply a field, an automated test can fill that field and continue the conversation. Provide the value through an objective mock, a same-key payload variable, or an explicit value in the conversation instructions.

For example, a child-ticket field named warehouseResolution can receive Replacement approved. The test then continues through the objectives and transitions that depend on that result. If no value is available, the test stops rather than fabricating a human-agent response.

Write the assertion for the complete journey after the child ticket is resolved, not only for the handoff message.

Multi-Message Replies​

A workflow can send an informational reply and continue, emit a child-ticket message before resuming, or split a long reply into several messages. The test waits for the remaining AI messages before producing the next simulated customer response, so intermediate messages do not prematurely end the turn.