Create a Repeatable Workflow Test

A workflow test simulates a customer conversation and checks whether the AI reaches the expected outcome. Save tests for important customer journeys, then run them again after changing a task, workflow, prompt, or data source.

Good candidates include order-status questions, refund requests, lead qualification, troubleshooting, and escalation to a support team.

Choose How to Create the Test

You can start a test in four ways.

Generate a Test with Copilot

Use Copilot when you want test ideas for a task or workflow. Describe the behavior or edge case you want to validate. Copilot drafts the customer instructions, completion condition, assertion, payload, and relevant mockable data points for you to review.

For example:

Create a test where a customer asks about a delayed order. The test should pass only if the AI explains the delay and gives the correct next step.

Review every generated field before creating or running the test. In particular, confirm that the assertion describes the expected outcome and that the suggested mock values create the intended scenario.

Record a Test AI Conversation

Use Test AI when you want to explore the journey yourself first.

1. Have the customer conversation in Test AI.
2. Confirm that the conversation represents the scenario you want to preserve.
3. Select Record for test.
4. Review the saved instructions and assertion.

Recording is useful for regression tests: once a real conversation works correctly, save it and run it again after future changes.

Create a Test Manually

Go to Workflows → Test Instructions and select Create. Manual creation is useful when you already know the exact scenario and expected result.

Provide:

• Name: a short description of the behavior under test.
• System prompt: instructions for the simulated customer, including what they know, what they ask, and how they should respond.
• Phone number: an optional customer identity for the run.
• Max turns: a safety limit for the conversation.
• Completion prompt: when the conversation has reached its intended end.
• Assertion prompt: the conditions that determine whether the run passes or fails.
• Payload variables: information available to the simulated customer.
• Objective mapping: stable values to use for selected workflow data points.

Clone an Existing Test

Select Clone from Test Instructions when a new case is a variation of an existing one. Change the name, input values, expected outcome, and any mocks that differ.

Cloning is a good way to build a small test matrix, such as separate cases for an order that is processing, delayed, delivered, or cancelled.

Payload and Objective Mocks

Payload and objective mocks serve different purposes. Do not use one as a substitute for the other.

Input	Represents	Visible to the simulated customer?	Example
Customer payload	Facts the customer starts with or can provide during the conversation	Yes	orderId: ORD-1042
Objective mock	A controlled value that the workflow would normally obtain from a data point or action	No	orderStatus: delayed

For an order-status test, the payload can give the simulated customer an order ID. The objective mock can make the order lookup return delayed. The customer should know the ID, but should not know the lookup result before asking the AI.

When you configure a run, Flowcall lists the data points that can be mocked. Select a data point to add it, then enter the value needed for the scenario. Only mock values that matter to the behavior you are testing.

Objective mocks make a test reproducible. Without a mock, the same order may be delayed today and delivered tomorrow, or an external service may be unavailable. The conversation could then take a different path even though the workflow did not change. A mock keeps the starting conditions stable, so a changed result is more likely to reflect a product or workflow change.

Write a Focused Test

Keep each test centered on one behavior. The customer instructions, completion condition, assertion, payload, and mocks should all describe the same scenario.

For example:

• Customer instructions: Ask for the status of order ORD-1042 and provide the ID when requested.
• Payload: orderId: ORD-1042.
• Objective mock: orderStatus: delayed.
• Completion: Finish after the AI explains the status and next step, or hands the conversation to support.
• Assertion: Pass only if the AI says the order is delayed and gives the expected next step. Fail if it claims the order is delivered or invents a delivery date.

Assertions and completion conditions often depend on the chosen payload and mock values. If you change the mock from delayed to delivered, update the expected completion and assertion as well. Otherwise, the test setup and its pass criteria will contradict each other.

Test a Child-Ticket Handoff

A flow may create a child ticket when it needs a human agent or another team to provide a value before it can continue. An automated test can simulate that resolution instead of ending at the handoff.

Provide the child-ticket field and its value in one of these places:

1. An objective mock with the same key as the child-ticket field.
2. A payload variable with the same key.
3. An explicit instruction in the customer script that states what value the simulated child ticket should return.

For example, if the child-ticket field is warehouseResolution, set warehouseResolution: Replacement approved as an objective mock or payload value. After the handoff message, the test fills that field and continues through the remaining objectives and transitions.

Prefer an objective mock when the value represents a result supplied by an agent, team, data source, or action. Use payload when the value is genuinely part of the customer's starting information. If the test does not provide a child-ticket value, the run stops with a clear missing-value result instead of inventing one.

Include the behavior after the handoff in the completion and assertion prompts. For example, assert that the AI acknowledges the replacement approval and explains the next step, rather than asserting only that a child ticket was created.

Conversations with More Than One AI Message

Some workflow steps send multiple messages before the customer should answer. Examples include a transition configured to reply and continue, a child-ticket handoff followed by its simulated resolution, and a long reply delivered in multiple parts.

The test waits for the complete group of AI messages before generating the next customer response. When reviewing a run, treat those messages as one workflow turn and verify both the intermediate information and the final reply when they matter to the assertion.

Run and Review

1. Open Workflows → Test Instructions.
2. Select Run for the saved test.
3. Review or change the phone number and customer payload for this run.
4. Select any data points you want to mock and enter their values.
5. Select Start run.
6. Review the conversation, completion result, assertion result, and any mocked values used by the run.

You can change run inputs without rewriting the reusable test. If a variation becomes important enough to run regularly, clone the test and save that case separately.

Related

• Testing — reference for test instructions, assertions, and mocking.
• Workflows — the workflows and data points exercised by a test.
• Copilot testing — draft tests and review test results with Copilot.