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 "failed" result and the MAIL_NOT_CONFIGURED code, 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 |
|---|---|---|
| Platform gateway | The platform's mail gateway | Your instance holds no provider keys. The default for instances provisioned by the platform. Does not support copies (cc) or threading, 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. No transport supports message attachments — the product's mail API doesn't carry them.
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.
The platform gateway is the exception
On the platform gateway page the address and token fields are usually empty, and that's normal: they are handed to the instance when it is provisioned. Fill them in only to override what was handed over — when moving an instance, or while debugging. The page shows which address is actually in use and where it came from.
Send-rate limits
The platform gateway page also sets its own limits — how many messages the instance sends per minute and per day (0 means no limit). These are not a copy of the platform's quotas but protection against them: exceeding a platform quota means a lost message, so the instance keeps its own lower limit and paces a batch out over time instead of running into a refusal.
In practice:
- sending one message out of a large batch can take a few seconds — that's expected, and the message still goes out;
- a limit set too low (a couple of messages per minute) does the opposite: the wait exceeds what's allowed and messages start failing with a rate error;
- the windows are sliding — the last 60 seconds and the last 24 hours, with no spike at midnight. The page shows how much was sent in both windows.
Bulk mailing isn't done through this channel: the gateway has no copies and no threading, and one message has a capped number of recipients.
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.
The log keeps the whole message: the full recipient list, the subject and the body. It answers not only "was it delivered" but "what exactly went out" — and for the same reason it holds customer correspondence and notification text. Bear that in mind when granting access to the administration area.
Where to go next
- Features & settings — enabling features.
- Search & notifications — what the notifications themselves look like.
- Automation — rules that send mail.