Templates and managed emails
Templates control the content users receive. Built-in emails cover common account, security, verification, recovery, and lifecycle messages.


Invitation template checklist
A good invitation email includes:
- recognizable app or company name
- clear reason the recipient is receiving the email
- organization or workspace name when relevant
- direct call to action
- expiration or next-step expectation
- support path or reply-to mailbox if users may be confused
Create a template
- Open Services > Email.
- Open Templates.
- Select Create template or Start from example.
- Write the subject.
- Write short body copy.
- Insert only the variables your template needs.
- Preview the message.
- Save.
- Send a test before broad use.
Variables
Templates can use variables for app, organization, inviter, recipient, action links, security context, and one-time codes. Built-in emails now expose their supported variables through the API so the UI can show the correct chips for each template instead of relying on a hard-coded list.
Avoid exposing raw internal IDs in user-facing emails unless your support process explicitly needs them.
Built-in emails
Review built-in emails by category before launch. Each built-in email has Switera-branded HTML, editable content fields, and MJML source for previewing and future editing.
| Category | Built-in emails |
|---|---|
| Sign-in | Magic link sign-in, passwordless code |
| Account trust | Email verification, email change confirmation |
| Account recovery | Password reset |
| Onboarding | Welcome email |
| Organization access | Invitation, invitation accepted, member added, member removed |
| Security | MFA enabled, MFA disabled, password changed, new device login, session revoked, account deleted |
For each email, decide whether it is active for launch, available later, or not needed for this app. Security and account-access messages should normally stay active because they explain account-sensitive events to end users.
MJML source
Managed previews return mjml_source together with rendered body_html and editable content fields. The source uses the app brand theme, including the logo, primary color, accent color, background, support email, and footer text.
The runtime sender still uses the rendered managed HTML path. MJML is the canonical authoring format for the catalog so later template editing can be safer and easier to validate.
Automation and timing
Use Automation to understand when each message sends.

Review:
- trigger event
- delay or immediate send behavior
- whether a workflow is active
- blocked recipient handling
- whether the workflow uses a custom or built-in template
Test checklist
- invitation renders correctly
- verification email reaches the inbox
- recovery email works
- links go to the expected hosted flow
- reply-to goes to a monitored mailbox
- unsubscribed or suppressed recipients are handled correctly
- audit logs show major email configuration changes
Related pages: