Overview
Test Action, already available for Generate with AI automations, now extends to Move Card automations. The test lets you simulate execution against the real pipe configuration and instantly see whether it would pass or fail, with the actual reasons why. No cards are moved and no data changes: it's pure validation before you publish anything.
What's new?
- Test Action for Move Card automations, available directly from the automation configuration. Click Test Action, select a card for the test, click Run Test, and get the result.
- Instant pass or fail result, with the exact failure reason: incorrect conditional fields, missing required fields, empty, nonexistent, or archived fields, or incorrect destination phase.
How does this help?
- Confidence to publish: you validate the automation against the real pipe configuration, with no need to simulate in a separate environment.
- Cuts cascading risk: since Move Card triggers a chain of downstream automations, testing before publishing prevents one wrong move from affecting the entire connected flow.
- Immediate diagnosis and lower production risk: instead of investigating after something already broke, you get the real failure reason at test time, apply the fix, confirm the fix worked, and reduce the risk of errors reaching production processes.
Use cases
1. Approval automation with multiple conditional phases
A Pipe Admin sets up a Move Card automation that depends on three conditional fields to decide the destination phase. Before publishing, they run Test Action and get a fail pointing to one of the conditional fields being archived. They restore the field, test again, before the automation ever runs in production, avoiding cards getting stuck or moving to the wrong phase.
2. Process with cascading automations
In a process with dozens of connected automations, the person responsible for modeling tests a Move Card automation in isolation before publishing a change. Test Action shows the automation would pass, but flags that a required field in the destination phase is empty, which would block the card in practice. They fix the field before releasing the change, without having to trace the issue automation by automation after the fact.
3. Reviewing an inherited automation
A Pipe Admin takes over an existing process and needs to validate a Move Card automation built by someone else, without full visibility into the configuration history. They run Test Action and find that the automation would fail because it depends on a phase that no longer exists in the current flow. This keeps them from publishing a blind fix or rebuilding the automation from scratch.
Most relevant for
- Pipe Admins
- Process modeling owners
- Operations teams managing critical automations
