The Email tab in Platform Settings gathers the platform's outbound email: who receives the plan-change notice, sample sends of each email template, and the log of what the platform has sent to every company. Only DataMind staff accounts can open the area; client settings live under Settings.
The tab is addressable: ?tab=email opens it directly. Three cards sit at the top; the sent-email
log fills the rest of the tab.
Plan change recipient decides where the notice about a real plan change goes. When a staff member changes a company's plan, the billing desk receives a notice with both plans, who changed it and when.
Using the deployment default of {address}.Integration settings updated or reports Update failed with the reason.Enter a valid email address, or clear the field to use the default.Saving here sends only this field. Notifications enabled, the switch that turns Discord notifications on or off, lives on the Integrations tab and is never touched from this card.
Two cards send a preview of a template with sample figures to any inbox; both are marked
Sample send. Each card's Send to field accepts an address, and leaving it empty sends to your
login email. A malformed address is refused with
Enter a valid email address, or leave it empty to send to yourself.
Usage alert emails renders one usage-alert template:
Premium tokens - 70% used, Premium tokens - allowance used up,
Standard tokens - 70% used, Standard tokens - allowance used up, Spend cap - 70% used,
Spend cap reached or Plan change suggestion. The selector starts on Spend cap reached.Test email sent, with Sent to {address} or
Sent to your login email; a failure reports Test email failed with the reason.Plan change notice renders the plan-change notice with two sample plans; click
Send test notice. The toast reads Test notice sent, or Test notice failed with the reason.
Tests touch no company: they do not change a subscription or an allowance, so send them as often as
you like. Each test leaves a row in the log below, marked Test, which makes it a live check that
mail works on this deployment. If the deployment cannot send mail, the send fails with
SMTP is not configured. A usage-alert test also needs the platform's console address to be
configured.
Sent emails lists every email the platform has attempted to send, across all companies, newest first. Each row is one send:
| Column | Shows |
|---|---|
| Sent | When the send was attempted. |
| Type | Invitation, Password reset, Usage alert or Tier change. |
| Status | Accepted, Failed or Skipped. |
| Recipient | The address the email was sent to. |
| Subject | The subject line of the message. |
| Company | The company the email is about, when one applies. |
| Test | A Test badge on a preview send; empty on a real one. |
| Error | The reason on a failed or skipped send; empty otherwise. |
Status is the column to read carefully:
| Status | Means |
|---|---|
| Accepted | The mail server took the envelope. Delivery is not tracked on this transport, so a bounced address still shows Accepted. |
| Failed | The send was attempted and did not go through; Error names the reason. |
| Skipped | No mail is set up on the platform, so nothing was attempted; Error reads SMTP not configured. |
Accepted = the mail server took it. Treat Accepted
as proof of sending, never as proof of delivery.
The toolbar's Refresh log reloads the table. The search box covers the recipient, subject,
company and error text, and the column filters offer type, status, company, test and recipient
values. The export action writes the current view, with the file named email-logs. The table works
like the console's other tables; see Tables overview.
The log keeps the details of a send, never the message itself: the body of an email is not stored here.
Nothing sent yet.What each email means to its recipient is on Emails from DataMind Platform.
Every email the platform attempts to send, for every company: Invitation, Password reset, Usage alert and Tier change rows, plus preview sends marked Test.
No. Accepted = the mail server took it. The platform
gets no delivery receipt, no bounce callback and no open tracking, so a bounced address still records
Accepted. The row proves the send, not the arrival.
Skipped means no mail is set up on the platform, so nothing was attempted; the Error column
reads SMTP not configured. Failed means a send was attempted and did not go through; the
Error column carries the reason.
No. The log only records sends; it has no resend control, and a failed send is never retried automatically. Repeat the action that produced the email, for example resend the invitation, or use a test send to check that mail works.
The log records the sends the platform attempted, and some non-sends leave no row. When the platform's console address is not configured, the invitation and password-reset paths stop before the mail step. Sends made before the log existed left no row either.
To the deployment default, which the platform falls back to whenever Notice goes to is empty. The card keeps showing In use: with the address that applies today.
No. Save recipient sends only the recipient field. Notifications enabled lives on the Integrations tab and is not changed from this card.
Yes. Fill Send to on either test card; leave it empty to send to your login email.
No. A test renders the template with sample figures and does not change any company's subscription or allowance, so send as often as you like. It does leave a row in the log, marked Test.
The deployment cannot send mail until mail is set up on it, so nothing was sent. Until then, real sends are recorded as Skipped rows.
The company the email is about, which is not always the recipient's company. It can be empty: password resets and owner invitations are not about a company.