Automations you can actually audit
16 trigger types, queued-leased-processed lifecycles, and why an automation you can't inspect is a liability instead of a shortcut.
Field notes · Built by Arche Axon
Most automation features are black boxes: you set a rule, hope it fires, and find out it didn't when a customer complains. That design failure is why 'automation' has a trust problem. An automation you cannot inspect is a liability instead of a shortcut.
What an auditable automation exposes
- Every trigger event has a lifecycle you can read: queued, leased, processed, failed, cancelled. If a rule did not run, the event record says why.
- Actions are scoped by permission keys. An automation cannot do something the account that created it could not.
- Execution status (success, failed, skipped, running) is recorded per run, so flapping rules are visible instead of legendary.
The trigger menu
Vendale's backend defines the trigger allowlist in one tuple: customer created or updated, conversation opened or message received, unassigned-threshold crossed, task created, completed, or overdue, order created or status changed, ticket created, resolved, or priority changed, broadcast completed or failed, and WhatsApp connection degraded. Sixteen triggers, one source of truth in the schema. The comment in our code says it plainly: the list used to live in two places and drift, and six triggers offered in a UI were rejected by the API. One source of truth is a feature, not a refactor.
The buying question this should hand you
Ask any vendor: 'show me where a failed automation run is recorded, and who can see it.' If the answer is a shrug, you are buying a black box.