Monitoring and audit
Once a workflow is active you need to answer two questions on demand: did it run, and did the customer get the intended outcome.
Where the answers live
The two questions are answered in different places, and it is worth knowing which before you go looking:
Trace a single case
Start from the trigger, since it is the record that links a workflow to a specific invoice or payment:
No trigger means the workflow never matched, so check its status, its customer scope, and whether the event actually fits the variant. A trigger with no email behind it means the workflow matched but the action did not complete. A trigger carries no result of its own, so the next step is the action configuration. Actions have their own status, and an inactive action on an active workflow produces triggers that do nothing:
Execution statuses
The executions table in Desk reports the outcome of each action against a trigger:
Alongside them the table reports whether an action that did run completed or failed, with the reason on the failed row.
PENDING and NOT_EXECUTED are the distinction worth reading carefully: an action skipped by its conditions has reached a final state and will not run for that trigger, where a pending one still will. Both look like “no email” from the customer’s side.
Expand the trigger on an action execution
GET /v1/workflow-action-executions/{id} and POST /v1/workflow-action-executions/search accept expand[]=workflow_trigger_id, which inlines the full workflow_trigger that produced the row:
Without it, building a list of executions with the resource each one acted on took a second call per row. Successful email actions also record a more useful reason, naming the invoice and the message ID the provider accepted, so a delivery can be traced from the execution log into the provider’s own logs without correlating timestamps.
workflow-action-executions is not yet covered by the generated API reference, so there is no schema page to link to yet.
Common failure causes
Via Desk
A workflow’s detail page includes a table of its action executions with the result and error message for each run. This is the only place execution outcomes are available, so it is where you start when a trigger exists but the customer got nothing.