# Test a Workflow (/how-to/workflows/test-a-workflow)



Before enabling a workflow on production data, you should test it with synthetic events to confirm the trigger, conditions, and actions behave as expected. Resytech provides a built-in test mechanism that publishes a real event through the same pipeline as production events, but with test markers so you can distinguish test executions from real ones.

Before you begin [#before-you-begin]

* The workflow must be **saved**. You do not need to enable it for testing -- the test endpoint publishes an event that the engine will process if the workflow is enabled, but you can also enable it temporarily just for testing.
* Make sure the workflow is **enabled** when you trigger the test. Disabled workflows are skipped by the event processor.
* Have the workflow execution log open in a separate tab so you can watch the results in near-real-time.

Steps [#steps]

1. Navigate to **Marketing > Workflows** and open the workflow you want to test.
2. Click the **Test** button (or open the test panel).
3. Select the **event type** to simulate. This should match the event type configured on your workflow's event node. Available test events:

| Event type                                     | What it simulates                         |
| ---------------------------------------------- | ----------------------------------------- |
| `booking_created`                              | A new booking being submitted.            |
| `booking_confirmed` / `booking_status_changed` | A booking status transition to Confirmed. |
| `booking_cancelled`                            | A booking being canceled.                 |

4. Optionally fill in **test event data** to customize the simulated event:

| Field           | Description                                    | Default if omitted                                       |
| --------------- | ---------------------------------------------- | -------------------------------------------------------- |
| **Booking ID**  | UUID of an existing booking to use as context. | A random UUID is generated.                              |
| **Customer ID** | UUID of an existing customer.                  | A random UUID is generated.                              |
| **Activity ID** | UUID of an activity.                           | A random UUID is generated.                              |
| **Amount**      | The total booking amount.                      | `100.00`                                                 |
| **Status**      | The booking status string.                     | `Pending` (for created), `Confirmed` (for status change) |
| **Start Time**  | Booking start time.                            | Tomorrow at the current time.                            |
| **End Time**    | Booking end time.                              | Tomorrow, two hours from now.                            |
| **Reason**      | Reason for cancellation or status change.      | `Test cancellation` or `Test confirmation`               |

5. Check the **Mark as Test** checkbox (enabled by default). This prefixes status and actor fields with `[TEST]` so test executions are easy to identify in logs.
6. Click **Run Test**. The system publishes the event to EventBridge, which routes it to the SQS workflow queue.

What happens during a test [#what-happens-during-a-test]

1. The event is published to AWS EventBridge with the same structure as a production event.
2. The `WorkflowQueueProcessor` picks up the message from SQS and matches it against enabled workflows for the location.
3. If your workflow's event node matches the test event type, the workflow executes through its full graph: conditions are evaluated, actions are performed.
4. A `WorkflowExecution` record is created with the trigger event type and the test event data.
5. Each node visited creates a `WorkflowExecutionStep` record with its status (`completed`, `failed`, or `skipped`).

Using real booking data in tests [#using-real-booking-data-in-tests]

For the most accurate testing, provide the UUID of a **real booking** in the Booking ID field. This lets the workflow engine:

* Load the actual booking record for condition evaluation (e.g., `booking_value > 200`).
* Resolve the real customer email and phone number for communication actions.
* Reference real activity and location data for template variable replacement.

If you use a random UUID (the default), conditions that depend on booking data may evaluate differently than expected because no matching booking exists in the database.

Tips [#tips]

* **Test one path at a time.** If your workflow has conditions with true/false branches, run one test that satisfies the condition and another that does not, to verify both paths.
* **Check the execution log after each test.** Navigate to [Monitor Workflow Executions](/how-to/workflows/monitor-workflow-executions) to see the step-by-step results.
* **Watch for side effects.** Test actions execute for real. If your workflow sends an email, the email will be sent. If it updates a booking status, the status will change. Use test data or a staging environment if you want to avoid affecting real customers.
* **Disable the workflow after testing** if you are not ready for it to run on live events.
* **Delay actions schedule real jobs.** If your workflow includes a wait/delay, the test will schedule a real Hangfire job. The workflow will resume at the scheduled time.