Debug a rule using execution history

Every automation run is recorded. The Manual Executions tab logs each fire — when it happened, what triggered it, which branch matched, which actions ran, whether each succeeded or failed, and the full input/output payloads. This is your first stop when a rule isn’t doing what you think it should.

Before you start

• A rule you suspect isn’t behaving correctly
• Admin permissions to view the rules page

Steps

1. Open Manual Executions. Go to Settings → Automation Rules and switch to the Manual Executions tab.

2. Filter to your rule. Use the rule filter to narrow to just the rule in question. Optionally narrow further by date range or by status (success / failure / throttled).

3. Open a recent run. Click any execution to expand it. You’ll see:

   
   Trigger event — the conversation/case ID, the field that changed, the timestamp
   Conditions — each condition’s evaluated result (true/false) and the values it compared
   Branch matched — which branch’s actions ran (or “no branch matched” if conditions kept the rule from doing anything)
   Actions — each action’s status and any error message

4. Read the action payloads. For actions like Send Email Studio template or Webhook, the run record includes the full request body and response. This is what you need to debug downstream issues — wrong template language, malformed webhook payload, 404 from the receiver.

5. Cross-reference with the conversation timeline. Open the conversation referenced in the run. The internal events panel shows the rule’s effects from the conversation’s side — the tag that was added, the status change, the message sent.

Common debugging patterns

Rule isn’t firing at all

1. Filter Manual Executions for the rule. If there are no entries, the trigger isn’t firing.
2. Confirm the rule is enabled.
3. Confirm the trigger type matches the event you expect. (Most-common: picking Conversation created when you wanted Message received.)
4. If the trigger is Message received, confirm the message’s direction matches your conditions (inbound vs. outbound).

Rule fires but conditions don’t match

1. Open a run where you expected the rule to act.
2. Check each condition’s evaluated value. The most common gotcha is a custom field’s stored value (machine slug) differing from its display label — your condition is comparing against the wrong representation.

Action fails

1. Open the failed run.
2. Read the action error message. For HTTP-based actions (webhooks, Slack), the error usually includes the status code and response body.
3. For Send Email Studio template failures, confirm the template ID still exists and that the language being requested has a translation.

Rule fires twice for the same event

1. Open recent runs and check timestamps. Are they truly duplicates (within milliseconds) or separate triggering events (e.g., a status change and an agent assignment that arrived together)?
2. If duplicates, set up throttling per-conversation to coalesce them.

Webhook recipient not seeing payloads

1. Filter for the webhook action’s runs. Confirm the action shows success — Atender’s side is fine.
2. Read the response body the receiver returned. A 200 with an unexpected body usually means the receiver’s endpoint matched but the payload format is wrong.

Notes

• Execution history is retained for a limited window (the exact retention is in Settings — Conversation Resolution and your tenant’s data retention policy).
• Throttled executions are logged with status “throttled” and the reason (which throttle scope blocked them).
• Failed actions don’t stop the run — Atender continues to the next action in the branch and records the failure. If you need a rule to bail on first failure, use a webhook action with an explicit acknowledgment check downstream.

See also

• Throttle a rule to prevent spam
• Simulate a rule before enabling
• Trigger types reference