Auth & Form Triggers
The two triggers a person starts by using your app: authenticating, or submitting a form. Both are the usual entry point for onboarding, notification and CRM-sync workflows.
Auth Trigger
Fires on authentication lifecycle events.
automations:
- name: welcome-new-user
trigger:
type: auth
events: [signUp]
actions:
- name: welcome
type: email
operator: send
props:
to: '{{trigger.data.user.email}}'
subject: Welcome aboard
body: 'Thanks for joining, {{trigger.data.user.name}}.'
| Property | Description |
|---|---|
events |
Array of signUp, signIn, signOut, passwordReset, emailVerified. Required, at least one. |
| Event | Fires when |
|---|---|
signUp |
An account is created, by any enabled strategy. |
signIn |
A session is issued. |
signOut |
A session is ended by the user. |
passwordReset |
A password reset completes. |
emailVerified |
A verification link is followed. |
events is the trigger's only property. There is no way to narrow an auth trigger to a role, a domain, or an OAuth provider in the trigger itself — do that in the first action with a filter/continue gate.
signUp and emailVerified are not interchangeable. Under requireEmailVerification: true, signUp fires for an account that cannot yet sign in. If a welcome message should only reach real, reachable mailboxes, trigger on emailVerified.
Form Trigger
Fires when a top-level form is submitted.
forms:
- name: contact-request
# fields …
automations:
- name: route-contact-request
trigger:
type: form
form: contact-request
actions:
- name: createLead
type: record
operator: create
props:
table: leads
fields: { email: '{{trigger.data.email}}' }
| Property | Description |
|---|---|
form |
References forms[].name. Required. See Forms. |
The reference is cross-validated against your declared forms[] when the config is decoded, so a renamed form breaks sovrium validate rather than leaving an automation that never fires.
form is a form name, not a page path. This was a hard break from an earlier design in which the trigger pointed at the URL the form was rendered on. A form reachable from several pages now has one trigger, not one per route.
Submitted values arrive at {{trigger.data.<field>}}, keyed by form field name. For work that must finish before the submitter sees a response, prefer the form's own onSuccess handling — a form trigger runs the automation independently of the submission's reply.
Related Pages
- Triggers Overview — the nine trigger types at a glance.
- Forms Overview — declaring the
forms[].namethis references. - Submissions — what happens to the submitted record itself.
- Auth Actions — acting on users from inside an automation.
- Data & State — the
filter/continuegate for narrowing events.
Last updated July 27, 2026
This documentation was written with AI, so errors or outdated content are possible. Sovrium is in beta — contributions and corrections are welcome.