Automations
Looking for the plans you write before shipping a feature? That is a different page: Plans.
Optional. The core of Skene Cloud (the lifecycle, plans, events, Flows, and PR reviews) runs on a read-only connection. Automations are the one part that writes to your database, and they require an explicit read-write Supabase connection. Skip this page if you don't need Skene writing to your database.
An automation is a rule: when something happens in your database, take an action. A signup row lands in your user table, send the welcome email. Skene compiles each rule into a state machine and deploys it as a Postgres trigger in your own database.
Automations live on the Actions page (/workspace/<slug>/agent-actions). You can browse and edit them with any connection; turning one on requires read-write.
Two ways to create an automation
1. Premade templates
Open Actions and create from the template library:
| Template | Trigger | Action |
|---|---|---|
| Triggerbeat | INSERT on any table | Fire analytics event |
| Welcome Email Drip | INSERT on your user/account table | Send welcome email |
| Inactivity Re-engagement | Scheduled (7+ days idle) | Send re-engagement email |
During deploy, Skene matches the template to your schema and asks you to confirm the table mapping. Welcome Email Drip works with any table that stores user accounts or signups (users, auth.users, accounts, customers, or your own naming). Emails send through Resend if you've connected it; without Resend, they run through a built-in test handler that previews the send without delivering it.
2. Skene Agent
Describe what you want in natural language, from the agent rail on the Lifecycle page or the assistant panel on an automation's detail page:
- "Send a welcome email when a user signs up"
- "Alert me when a user hasn't logged in for 14 days"
The Agent proposes a definition (trigger table, conditions, action) and saves it as a draft. You refine it in conversation, then review and deploy it with the same schema matching as templates.
Compile and deploy
Compile turns a definition into a deployable state machine. Skene introspects your schema and generates:
- Conditions that control when the rule fires: state checks ("only in the signup stage"), cooldowns ("at most once per 7 days"), max-fire limits ("once per user, ever")
- Effects that describe what happens: state transitions, journey events, metadata updates
Deploy pushes the trigger into your Supabase project, after a review step where you confirm or override the proposed table and operation. A deploy creates one Postgres trigger per unique table and operation; automations watching the same table and operation share a single trigger. See Supabase Integration: Deploying triggers for what exactly lands in your database.
Statuses
Draft -> Paused <-> Active
| Status | Trigger state | Events processed? |
|---|---|---|
| Draft | Not deployed | No |
| Paused | Deployed but suppressed | Events logged, but the automation is left out of dispatch entirely |
| Active | Deployed and firing | Yes: conditions evaluated, actions executed |
| Archived | Kept for history | No. Set when a synced engine.yaml no longer includes it; shown read-only |
Newly deployed automations start Paused: nothing fires until you turn it on. Deleting one removes it permanently; the Postgres trigger is removed from your database only if no other automation shares the same table and operation.
Next steps
- Logs: Monitor automation decisions and action results
- Supabase Integration: Trigger deployment details and cleanup