Workflows & Automation
Monitor Workflow Executions
How to track workflow execution history, inspect step-by-step logs, and troubleshoot failures.
Every time a workflow runs, Resytech creates a detailed execution record with step-by-step logs. This guide explains how to read execution data, understand statuses, and diagnose common problems.
Viewing execution history
- Navigate to Marketing > Workflows.
- The workflow list shows summary stats for each workflow:
| Column | Description |
|---|---|
| Name | The workflow name. |
| Enabled | Whether the workflow is currently active. |
| Executions | Total number of times the workflow has run. |
| Last Executed | Timestamp of the most recent execution. |
- Click a workflow to open its detail page. The execution history tab lists every execution in reverse chronological order.
Execution record fields
Each execution record contains:
| Field | Description |
|---|---|
| Execution ID | A unique GUID for this execution run. |
| Workflow ID | The workflow that was executed. |
| Trigger Event Type | The event that fired the workflow (e.g., Booking Created, Booking Status Changed). |
| Trigger Event Data | The full JSON payload of the triggering event, including booking ID, customer ID, amounts, and timestamps. |
| Status | The overall execution status (see below). |
| Started At | When execution began. |
| Completed At | When execution finished (null if still running or paused). |
| Error Message | The error message if the execution failed. |
Execution statuses
| Status | Meaning |
|---|---|
running | The workflow is currently being processed. |
completed | All nodes executed successfully. |
paused | The workflow hit a delay/wait action and is waiting to resume. A Hangfire job is scheduled to continue execution at the configured time. |
failed | An action or condition threw an error. The error message is stored on the execution record. |
Execution steps
Each node visited during execution creates a step record:
| Field | Description |
|---|---|
| Step ID | Unique identifier for this step. |
| Node ID | The graph node that was executed. |
| Node Type | event, condition, or action. |
| Status | running, completed, failed, paused, or skipped. |
| Input Data | The node's configuration (JSON) -- what was configured in the workflow builder. |
| Output Data | Result data (JSON). For condition nodes, this includes the boolean result. |
| Error Message | The error message if this specific step failed. |
| Started At / Completed At | Timing for this individual step. |
Reading condition step output
A condition step's output data looks like:
{ "result": true }This tells you which branch was taken. If result is true, execution followed the default (true) edge. If false, it followed the edge marked with type false.
Diagnosing failures
Step failed: action error
When an action step fails, the error message is saved on both the step and the execution. Common causes:
| Error message | Likely cause | Fix |
|---|---|---|
Failed to send email: ... | Invalid recipient email, SMTP configuration issue, or M365 credential problem. | Check that the recipient template variable resolves to a valid email. Verify company email settings. |
Webhook failed with status 4xx/5xx | The external endpoint returned an error. | Check the webhook URL and authentication headers. The response body is logged. |
Webhook URL targets a blocked address | SSRF protection blocked the URL. | Webhook URLs cannot target localhost, private IPs (10.x, 172.16.x, 192.168.x), or cloud metadata endpoints. Use a public URL. |
Webhook request timed out | The external endpoint did not respond within 30 seconds. | Ensure the target endpoint is reachable and responds quickly. |
Failed to update booking status: ... | Invalid status transition. | The booking status change pipeline validates transitions. Check that the target status is a valid next state. |
SMS service not initialized | Twilio credentials are not configured. | Set up Twilio integration in your company settings. |
Template not found or inactive | The referenced communication template was deleted or deactivated. | Re-activate the template or select a different one. |
Booking not found | The booking UUID from the event does not exist in the database. | This can happen with test events that use random UUIDs. For production, this indicates a data issue. |
Execution paused but never resumed
If an execution stays in paused status indefinitely:
- Check the Hangfire dashboard for the scheduled resumption job.
- Verify that the Hangfire worker service is running.
- If the delay was relative to a booking time and the booking was rescheduled, the resumption job automatically recalculates the fire time. Check Hangfire logs for rescheduling messages.
- If the calculated resumption time is in the past (for example, a "24 hours before booking start" delay on a booking that starts in 12 hours), the workflow resumes immediately.
Workflow did not fire
If an event occurred but the workflow did not execute:
- Is the workflow enabled? Disabled workflows are skipped.
- Does the event node match? The event type in the workflow's event node must match the incoming event. A
booking_status_changedevent can match bothbooking_status_changedandbooking_confirmed(orbooking_canceled) workflow triggers. - Is the location correct? Workflows only fire for events from their own location.
- Check the SQS queue. If the event was not published to EventBridge, no workflow can fire. Check that the
IEventPublisheris configured and the EventBridge bus is reachable.
Execution limits and safety
- Maximum 100 nodes per execution. If the graph is traversed beyond 100 nodes, execution aborts with an error. This prevents runaway workflows.
- Cycle detection. Each node can only be visited once per execution. If the graph has a cycle, the second visit to a node is silently skipped.
- Concurrent execution limit. The queue processor runs up to 10 workflow executions concurrently. Additional messages wait in SQS.
- Visibility timeout. Each SQS message has a 5-minute processing window. If processing takes longer, the message returns to the queue and may be retried.
- Non-blocking event publishing. If the event publisher fails when a booking is created, the booking is still saved. Workflow event publishing never blocks or rolls back the primary operation.