Automations you can actually audit
The current source trigger set, its event lifecycle, and why an automation you cannot inspect needs careful evaluation.
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
The current source defines 18 trigger types: customer created or updated; conversation opened, message received, or unassigned threshold; task created, completed, or overdue; order created, status changed, or cart abandoned; customer inactivity threshold; ticket created, resolved, or priority changed; broadcast completed or failed; and WhatsApp connection degraded. This is a source-code count, not a promise that every trigger is included in the current invite-only release. Check the release record and the installed automation editor before designing a live workflow.
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.