# 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.

```yaml
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`](/en/docs/automation-data-actions) gate.

:::callout
**`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.

```yaml
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](/en/docs/forms-overview). |

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.

:::callout
**`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](/en/docs/automation-triggers) — the nine trigger types at a glance.
- [Forms Overview](/en/docs/forms-overview) — declaring the `forms[].name` this references.
- [Submissions](/en/docs/form-submissions) — what happens to the submitted record itself.
- [Auth Actions](/en/docs/automation-auth-actions) — acting on users from inside an automation.
- [Data & State](/en/docs/automation-data-actions) — the `filter/continue` gate for narrowing events.