Workflows & Automation
Test a Workflow
How to fire test events to verify your workflow logic before it processes real bookings.
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
- 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
- Navigate to Marketing > Workflows and open the workflow you want to test.
- Click the Test button (or open the test panel).
- 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. |
- 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 |
- 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. - Click Run Test. The system publishes the event to EventBridge, which routes it to the SQS workflow queue.
What happens during a test
- The event is published to AWS EventBridge with the same structure as a production event.
- The
WorkflowQueueProcessorpicks up the message from SQS and matches it against enabled workflows for the location. - If your workflow's event node matches the test event type, the workflow executes through its full graph: conditions are evaluated, actions are performed.
- A
WorkflowExecutionrecord is created with the trigger event type and the test event data. - Each node visited creates a
WorkflowExecutionSteprecord with its status (completed,failed, orskipped).
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
- 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 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.