Emails

When the project configures emails: in plugin options and wires an email adapter (e.g. @payloadcms/email-resend) into the Payload config, @systhemaui/payload registers an Emails tab inside the general-settings global. The tab carries four editor-facing fields:

Field	Type	Purpose
emailFromName	text	The sender name shown in the recipient's inbox.
emailFromAddress	text	The email address emails are sent from. Must be verified with your email provider.
replyTo	text	Address for replies. Falls back to emailFromAddress if not set.
logo	upload	Image displayed at the top of the Systhema-branded email template.

Resolution order for outgoing email defaults is per-form override → general-settings.emails → plugin emails: option → adapter defaults / env. At runtime, Systhema wraps payload.sendEmail so every outgoing message (system + custom) picks up the global settings and the branded template; no per-call configuration is needed.

If neither emails: is set nor an email adapter is configured, the tab is not registered, no general-settings.emails.* columns are created, and payload.sendEmail keeps the adapter's default behavior untouched.

The per-form notification emails are a separate thing from the emails: templates module. A form's own Emails array — the recipients, subject and body a form sends on submission — appears on the Forms collection whenever the Payload config has an email adapter, with or without emails:. The templates module only adds the General Settings defaults on top. Without it, a form's notifications resolve from the form's own values and then the adapter's defaultFromAddress/defaultFromName; nothing queries General Settings. The array is only removed when there is no adapter at all, since there would then be no way to send.

Upgrading from the standalone Emails globalLink to this section

Projects upgraded from a version that shipped the old standalone Emails global get their existing data copied into the new tab automatically as part of systhema upgrade — the CLI runs pnpm payload migrate-emails-to-general-settings (a Payload bin script registered by @systhemaui/payload) right after pnpm install. The script is idempotent: it no-ops if there's nothing in the old emails table/collection, and re-running after success reports "already migrated" without overwriting. Pass --force to overwrite the new tab from the old data. The old emails DB table/collection is left in place after migration — drop it manually with a SQL DROP TABLE (Postgres) or db.emails.drop() (Mongo) if you want a clean schema. Custom roles defined in non-.ts/.tsx files (JSON, YAML, DB rows) that reference global.emails.read or global.emails.update are NOT touched by the auto-codemod — sweep them manually.

AccessLink to this section

Capability for editor access: global.general-settings.emails.update. See Access control → Built-in roles above for how to grant it to a custom role.