> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.solvimon.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.solvimon.com/_mcp/server.

# 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:

| Question                                             | Where                                                                    |
| ---------------------------------------------------- | ------------------------------------------------------------------------ |
| Did the workflow match this invoice or payment?      | Workflow triggers, in the API or in Desk.                                |
| Did the action succeed or fail, and why?             | The executions table in Desk. The API does not expose execution records. |
| Was the email delivered, bounced, or marked as spam? | Your email provider's own logs. Solvimon only reports the hand-off.      |

## Trace a single case

Start from the trigger, since it is the record that links a workflow to a specific invoice or payment:

**`Find the triggers a workflow produced`**

```bash Find the triggers a workflow produced
curl -X POST https://test.api.solvimon.com/v1/workflow-triggers/search \
  -H "X-API-KEY: <apiKey>" \
  -H "Content-Type: application/json" \
  -d '{
    "filter_fields": [
      { "name": "workflow_id", "value": "wf_7KcQm1RtbXeUvL2NpHZ4S" },
      { "name": "customer_id", "value": "cust_AbD3DqausjOYiMNDZY11F" }
    ]
  }'
```

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:

**`List actions and check their status`**

```bash List actions and check their status
curl -X GET "https://test.api.solvimon.com/v1/workflow-actions?limit=50" \
  -H "X-API-KEY: <apiKey>"
```

## Execution statuses

The executions table in Desk reports the outcome of each action against a trigger:

| Status         | Meaning                                                                      |
| -------------- | ---------------------------------------------------------------------------- |
| `PENDING`      | The action is queued and has not run yet.                                    |
| `NOT_EXECUTED` | The action was skipped because the trigger's conditions did not hold for it. |

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:

**`Search executions with the trigger inlined`**

```bash Search executions with the trigger inlined
curl -X POST "https://test.api.solvimon.com/v1/workflow-action-executions/search?expand[]=workflow_trigger_id" \
  -H "X-API-KEY: <apiKey>" \
  -H "Content-Type: application/json" \
  -d '{}'
```

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.

> **Note**
>
> `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

| Symptom                                   | Likely cause                                                                                        |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------- |
| No trigger at all                         | Workflow is not `ACTIVE`, or the customer is outside `customer_ids`.                                |
| Trigger exists, no email                  | Action is not `ACTIVE`, or the email integration is inactive or its sending domain is not verified. |
| Execution failed on render                | `template_name` does not exist on the provider, or the customer's locale has no template.           |
| Email sent without a pay link             | `include_payment_link` is set but payment collections are not configured.                           |
| Email sent, customer says nothing arrived | Delivery problem downstream. Check the provider logs for bounces and spam complaints.               |

## 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.

## API reference

* [Search workflow triggers](https://docs.solvimon.com/api-docs/transaction-api/workflow-triggers/post-workflow-triggers-search)
* [List workflow triggers](https://docs.solvimon.com/api-docs/transaction-api/workflow-triggers/get-workflow-triggers)
* [List workflow actions](https://docs.solvimon.com/api-docs/configuration-api/workflow-actions/get-workflow-actions)