Email
This page is for administrators. It covers how TaskFlow sends email: password resets, notifications, Service Desk replies to customers and mail sent by automation rules.
How email works here
TaskFlow has no mail settings of its own and no built-in SMTP client. Sending is done by a transport — a feature you enable, fill in with your provider's credentials, and then assign to the kinds of mail it should carry.
That means two steps, and both are needed before anything is delivered:
- Enable and configure a transport.
- Assign it to a purpose — otherwise mail of that kind simply isn't sent.
There is no fallback
If no transport is assigned to a purpose, mail of that purpose is not delivered — it doesn't quietly go out through some other transport. The attempt is still recorded in the delivery log with a "not configured" result, so the gap is visible rather than silent. This is deliberate: which provider carries your mail is an administrator's decision, not something the system should guess.
Available transports
| Transport | Sends through | Notes |
|---|---|---|
| Relay | The platform's mail relay | Your instance holds no provider keys. The default for instances provisioned by the platform. Does not support copies (cc), threading or attachments, and is subject to quotas. |
| AWS SES | Amazon SES | Full support, including threading. |
| SendGrid | SendGrid Mail Send API | Full support. |
| Google Workspace | Gmail API, as a user of your Workspace domain | Requires domain-wide delegation to be set up on the Google side. |
Transports are not mutually exclusive — you can run several at once and route different mail through different providers.
Each transport declares honestly what it can do, and TaskFlow drops the fields it can't handle rather than failing: a message goes out without a copy or without being threaded, instead of not going out at all.
Setting up a transport
- Make sure the transport is permitted by your instance's configuration and enable it under Administration → Plugins (see Features & settings).
- Open Administration → Email and pick the transport from the nested menu.
- Enter the provider's credentials on its page. Credentials live here, in the interface — there are no environment variables for them.
- Send a test message to confirm the provider accepts it.
Assigning transports to purposes
Mail is grouped by purpose, and each purpose is assigned a transport separately:
| Purpose | Covers | Assigned on |
|---|---|---|
| System | Password resets and other account mail. | Administration → Settings |
| Notifications | Notification emails about issues you're involved in. | Administration → Notification gateways |
| Service Desk | Replies sent to a customer when an agent answers their request. | Administration → Service Desk |
| Automation | Mail sent by the Send email action in a rule. | Administration → Automation |
Each purpose is assigned where its feature is configured, rather than all in one list. The overall picture — which transport serves which purpose — is on Administration → Email.
Monitoring delivery
Administration → Email also holds the delivery log: every attempt, its result, and the reason when it failed. This is the first place to look when someone reports a missing password-reset link or a notification that never arrived — including the "no transport assigned" case described above.
Where to go next
- Features & settings — enabling features.
- Search & notifications — what the notifications themselves look like.
- Automation — rules that send mail.