Notifications

Settings → Notifications (/admin/settings/notifications), headed Notification Settings, configures two entirely separate channels:

• In-app notifications — the panel in the bottom-right corner of the app, and the notification rows behind it. Local to your instance, no external service.
• Email notifications — messages delivered through the hosted SeqDesk relay. Off by default, and gated by more conditions than the switch on this page.

Facility admins only. Changes take effect on Save changes, immediately, with no restart.

In-app notifications

One switch, on by default. It governs GET/POST /api/notifications: with the switch off, the API answers enabled: false with an empty list, so the panel disappears and no new notification rows are created. Nothing already stored is deleted, and turning the switch back on makes the history visible again.

In-app notifications are generated for sequencing order creation and updates, for terminal pipeline run states, and for application-update progress. They never leave the instance, so they work on a deployment with no outbound network access at all.

Email notifications

The four conditions

An email is only sent when every one of these holds. Missing one is the usual reason a facility believes email is on and no mail arrives.

Then two more per-recipient checks run: the recipient’s own preferences must allow this class of mail, and the address must be a real one.

The provider is fixed at seqdesk-relay; there is no SMTP option. The relay URL defaults to https://seqdesk.org/api/notifications/relay. Your instance POSTs the event name, the recipient, a small context object (order number, status transition, actor name, a snippet truncated to 240 characters, a deep link) and identification for the installation. Message bodies are rendered by the relay, not by your instance.

Email event triggers

Five events, all on by default once email itself is enabled. A disabled event is never sent to the relay at all.

Direction is enforced in code, not by configuration: a status change made by a researcher sends nothing, and an admin marking samples sent or opening a ticket does not notify the admins about themselves.

Replies are addressed sensibly — mail to a researcher carries the facility’s reply-to address, and mail to admins carries the researcher’s address — so a plain Reply reaches a human.

Email user defaults

Two switches, Sequencing Order email notifications and Support email notifications, both on by default. They set the starting preference for newly created accounts only. Existing users keep whatever they chose in their own Settings → Email Notifications, where the same two preferences appear as Sequencing Orders and Support.

Because these are defaults rather than overrides, flipping them off does not silence anyone who already has an account.

Who is skipped

Even with everything enabled, the dispatcher refuses a recipient when:

• The account is a demo account.
• The address is not a syntactically valid email.
• The address is a placeholder — admin@example.com, user@example.com, or anything ending in @seqdesk.local. The bootstrap admin created by the installer often has exactly such an address, which is why a test to yourself can be skipped on a fresh instance.
• The recipient’s own preference for that class of mail is off.

Dispatch is best-effort throughout: a relay failure is logged and never blocks the action that triggered it. Submitting an order always succeeds, whether or not the email goes out.

Verifying the setup

Troubleshooting

See also

• Modules — the master gate for email
• Configuration Sources & Priority — why a saved setting can be overridden
• Support & Messages — the ticket flow behind two of the events