Practical guide

An automation did not behave as expected

Last materially reviewed 2026-09-20

Quick answerPreserve the original record and establish what actually happened before retrying an action that might contact someone.
What to know

Troubleshooting: an unclear result is not a safe retry signal

An automation may fail before acting, complete partly or act while its visible result remains unclear. Preserve the original record and inspect supported evidence before triggering it again. This matters especially for messages or actions affecting another system. A replacement opportunity or duplicated task can conceal the first outcome and cause repeated contact. Capsule’s documentation explains supported workflow conditions; your recovery process must still distinguish a known failure from an uncertain result.

What to know

Diagnose the original conditions

Identify the trigger, stage, recipient, mailbox connection and configuration that applied at the time. Do not edit several settings simultaneously and then claim to know which one caused the problem. Compare actual evidence with the expected test case. If a required connection or recipient condition was absent, address that specific issue through an authorized process. Keep credentials and private message content out of general troubleshooting notes or screenshots.

What to know

Reconcile before repeating a chargeable or external action

Check whether the intended task, project or message already exists. Use original identifiers and supported history where available. If the product cannot establish the outcome, stop further automatic action and obtain a precise recovery path rather than assuming no response means nothing happened. This guide does not claim exactly-once delivery or automatic rollback. A manual decision may be necessary to preserve the customer relationship while the technical state is clarified.

What to know

Retest the changed condition

After a justified repair, use fictional records to test both the normal path and the observed failure case before expanding live use. Record what changed and who owns the configuration. Keep a clear way to stop future actions without deleting the evidence of past attempts. Continue to pre-activation testing and duplicate-outreach prevention. A successful recovery is one whose actual outcome is understood, not merely a fresh run that returns a reassuring message.

Continue when useful

Next: Test an automation before activating it

Demonstrate trigger, recipient, action and stop conditions with fictional records before involving customers.

Open Test an automation before activating it →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Capsule workflow automation — Merchant documentation · capsulecrm.com · Merchant-controlled · checked 2026-09-20