Notifications & Email
The platform notifies people in-app and, when email is configured, by email. Email delivery is provided through a pluggable foundation that supports Resend today; an SMTP transport exists as a wiring stub.
#Purpose
#Architecture
A notifications system records events (for example, a won lead or a pending approval) and surfaces them in the notification center; users manage their own notification preferences.
Outbound email runs through an email foundation selected by an EMAIL_PROVIDER setting: none (default, nothing is sent), resend (working provider), or smtp. In this build the SMTP transport is a stub and requires additional wiring to enable.
#How it works
Event occurs
Notify in-app
Email (if configured)
User acts
#Reference
#Email providers
| EMAIL_PROVIDER | Behavior |
|---|---|
| none (default) | No email is sent |
| resend | Sends via Resend (working) |
| smtp | Transport is a stub in this build; needs additional wiring |
#Implementation notes
- Notification preferences are per user.
- EMAIL_FROM sets the sender identity used by the provider.
- Invitations, notifications, and invoices all depend on a working email provider.
#Limitations
Known limitations
- Without a configured provider, no email is sent (in-app notifications still work).
- The SMTP path is a stub in this build; Resend is the supported provider.
#Security considerations
Security
- Email provider credentials are server-side secrets.
- Use a domain-aligned sender to aid deliverability.
- Do not leak recipient data in logs.
#Best practices
- Configure and test email early.
- Prefer the supported provider for reliability.
- Keep critical notifications enabled for users.
#Related documentation
Provider setup.
What triggers email.
User-facing.
Still need help?
Can’t find what you’re looking for? The DevSphere OS team is happy to help.