The Notifications screen controls which audit events can be sent by SMTP email and which addresses receive them. The mail server connection lives on the separate Server settings > SMTP tab; the live notifications in the topbar are a different, per-session feature.
Access, role, and license boundary
Owner, Admin, and Auditor can open Notifications. Only the Owner can change recipients or event selections, save settings, and send an SMTP test. Admin and Auditor see the same data read-only. The User role cannot view system settings and therefore cannot open this screen.
Notifications needs no separate license feature. Read-only on this screen refers to a non-Owner role, not the license. A read-only license does not disable these server settings or SMTP tests for an Owner; apply any stricter policy of your own separately.
What you can do here
- Read the SMTP on/off state, recipient count, and selected event-rule count.
- Add or remove addresses under Email recipients; duplicates are merged.
- Use Test recipient to check the current SMTP form values before saving.
- Filter the event catalog with All, Selected, Info, Suspicious, and Critical.
- Change one event, a whole severity group, or the full catalog’s email selection.
- Read each row’s Immediate, cooldown, or threshold policy before balancing visibility and noise.
- Save notifications and Reset act on the whole form shared by Notifications and the other Server settings tabs. Do not use either while another tab has unsaved changes.
Screen structure
The Notifications screen has no tabs of its own. It contains a status strip and two main areas:
- The SMTP status button and SMTP settings open Server settings > SMTP.
- Delivery contains the recipient list and SMTP test.
- Event rules contains filters, bulk selection, severity groups, and individual event rows.
Ready to send means only that SMTP is on in the form, host and sender are filled in, and at least one recipient and event are selected. It does not prove that the mail server connection works, that a mail server accepted a message, or that a recipient received it.
Delivery and SMTP
Recipient list
Separate recipients with a new line, comma, or semicolon. Before saving, addresses are lowercased, blank entries are removed, and duplicates are kept only once. While SMTP is on, host, sender email, and at least one recipient are required. When authentication is on, a username and either a new or already saved password or token are required.
Notifications does not edit the SMTP account name, host, port, sender, TLS/STARTTLS, username, or password. Manage those on the SMTP settings tab. When SMTP is off, the connection details are kept; audit records and in-session notifications continue while email stops. Emails that would have been sent during that time are discarded and are not sent later when SMTP is turned back on.
Test delivery
Send test is available only to the Owner, while SMTP is on, and while no other test is running. A test requires:
- A valid port (1–65535),
- SMTP host and sender email,
- A separate Test recipient,
- When authentication is on, a username and either the password or token in the form or one saved earlier.
The test can use unsaved SMTP values. While SMTP is on, at least one notification event must be selected; with none selected, the button may look available but the test is refused. Repeated tests in a short time are refused for a while. An address in the success notice means the mail server accepted that recipient; it does not prove the message reached the inbox and was not quarantined. A successful test is recorded in the audit history. A failed test shows an error on screen and in notifications. The test email is currently written in Turkish; changing the interface language does not change it.
Event rules and severity groups
Filters change only the visible rows, not the saved selection:
| Filter | Shows |
|---|---|
| All | Every audit event that can be emailed. |
| Selected | Events currently selected for email. |
| Info | Maintenance and informational events. |
| Suspicious | Suspicious access and review-required signals. |
| Critical | Critical security and action-required events. |
Select all marks every event. Clear removes all marks. If SMTP is on with no event selected, Save notifications stays disabled and the SMTP test is refused; select at least one event before saving or testing. If SMTP is off, settings can be saved with no event selected.
The checkbox in a severity header selects or clears the whole group; a partial selection shows a mixed checkbox. A row changes only its own event. Unselected events are not deleted and stay in Audit Log; they are not emailed.
Delivery policy
Selecting an event does not mean every occurrence sends an email at once. Each row shows its policy:
- Immediate: the event is queued for email when it happens.
- First event, then Nm cooldown: the first event is emailed and the same group stays quiet during the cooldown.
- N events / Mm: the event is emailed only after the threshold is reached within the stated time.
Grouping can be by actor or by actor and target, depending on the event. The server queues emails and retries temporary failures a few times; a permanent rejection or too many failures can still prevent delivery. Notifications has no per-recipient delivery receipt, read status, or sending history. Event selection and Rules ready are therefore not delivery guarantees.
Live notifications and persisted events are different
The topbar bell and the short-lived pop-up notifications show action successes, errors, and system messages in this browser session. Only a few pop-ups appear at once. The bell keeps recent notifications for this session and shows the newest; repeated identical messages are merged.
Mark read keeps the times while marking current entries read. When read entries exist, Clear read removes only them; if none are read, Clear all empties the list for this session. Dismissing one row also removes its pop-up if still visible.
This list is not saved on the server and does not come back after a page reload or new session. Clearing the bell does not delete Audit Log entries, queued email, saved event rules, or sent email. An audit event does not always produce a pop-up or an email.
Recommended workflows
Verify a first SMTP notification setup
- Under SMTP settings, turn SMTP on and enter host, port, sender, TLS, and authentication when required.
- Return to Notifications and add at least one real recipient.
- Start with a small event set and read each row’s threshold or cooldown policy.
- Choose Send test for a separate test recipient and confirm the mail server accepted it.
- Check the inbox, spam or quarantine, and your mail gateway separately.
- Confirm that no other Server settings tab has unsaved changes; then choose Save notifications, reopen the screen, and confirm the recipient and event counts remain.
Reduce noise
- Use Selected to show only events selected for email.
- Review threshold and cooldown policies for high-volume rows first.
- Clear rows that need no human action; clear a whole severity group only after an explicit decision.
- Save and confirm unselected events still appear in Audit Log.
Screen states
| State | Operator response |
|---|---|
| Server settings loading | There is no placeholder here; do not treat the temporary SMTP-off form as the real state or save before the values load. |
| Server settings unavailable | The panel may show no error card. If expected recipients or rules are missing, check Server settings and the connection, then refresh; do not overwrite known settings with an empty form. |
| SMTP off | No email is sent; audit and in-session notifications continue. Emails due during this time are discarded and not sent later. |
| Needs attention | SMTP is on but host, sender, recipient, or event selection is incomplete. |
| Ready to send / Rules ready | Only the form is complete; testing and checking the recipient side are still needed. |
| No recipients | Add at least one valid address while SMTP is on. |
| No event selected | With SMTP on, at least one event is required before saving; even if the test button looks available, the test is refused. |
| No events in filter | Switch to All or another severity; the saved selection does not change. |
| Sending test | Do not start a second test; wait for the result or error. |
| Test accepted | The mail server accepted the address; check inbox delivery separately. |
| Test failed | Check host, port, TLS, authentication, sender, recipient, and network access without exposing credentials. |
| Role read-only | Admin and Auditor can review rules but cannot change, save, or test them. |
| Unsaved changes | The shared form also holds changes from other Server settings tabs. Save notifications can save them together; Reset can return them all to the last loaded values. |
| No live notifications | Only means this browser session has no new action result; it does not prove Audit Log is empty. |
Before you act
- Confirm your role; recipient, rule, test, and save actions require the Owner.
- Before Save notifications or Reset, confirm no other Server settings tab has unsaved values; both act on the whole shared form.
- Confirm SMTP is on and remember that Ready to send means only that the form is complete.
- Confirm approval, data classification, and on-call ownership for every recipient address.
- Read the event row’s severity and delivery policy; selection does not mean immediate email.
- Note the current recipient and selected-event counts before changing them, without putting real addresses in shared evidence.
- The test uses unsaved SMTP values and is limited to a few attempts in a short time.
- Do not use the bell as a substitute for Audit Log.
Safe evidence
- Safe to share: SMTP on or off, redacted host type, port and TLS mode, recipient count, event name and severity, delivery policy, general error, and broad time window.
- Keep private: SMTP username and password or token, real recipient and sender addresses, full host name, message ID, subject and body, audit target, user or vault name, exact incident time, and internal mail routing.
- When sharing a test result, mask the accepted address, SMTP host, and message ID; accepted does not prove final delivery.
- Do not rely on cropping alone in screenshots; fully mask addresses, hosts, event targets, users, times, and customer context.
When to stop and escalate
Stop if you cannot confirm the loaded values are current, expected recipients disappear, a test goes to the wrong address, SMTP credentials are exposed, critical events appear in Audit Log but no email arrives, or one rule sends unexpectedly many emails. Email support@vaultpilot.io with the general SMTP state, redacted event name, delivery policy, broad time window, error message, and last safe step, without secret material.
Operator notes
Notifications is not a mailbox or delivery-monitoring console. It stores recipients and event rules; SMTP connection details live under Server settings. Audit records, email sending, and in-session notifications each work separately.
Never share a notification example containing an SMTP password or token, real email address, customer host name, message ID, full error response, or incident-specific secret.