Notifications

Notifications in IssuesId are how the platform tells people something has happened — a defect was assigned to them, a distribution is awaiting their acknowledgement, an RFI needs a response.

There are two delivery channels: in-app (the bell icon at the top of the dashboard) and email. Most notifications go to both, but each user can tune their preferences.

What triggers a notification

Notifications are fired by workflow rules — the engine that watches for events and decides what to do about them. The platform ships with sensible defaults:

→Defect assigned to you → in-app + email.
→RFI awaiting your response → in-app + email.
→Distribution awaiting your acknowledgement → email (always — this is the receipt mechanism).
→Inspection ready for sign-off → in-app + email.
→Overdue defect on your project → digest email.

You can disable, modify, or add to any of these via workflow rules at the organisation or project level.

Per-user preferences

Each user has notification preferences for:

→Channels — email, in-app, or both, per notification type.
→Digest cadence — turn immediate emails into a daily or weekly digest.
→Quiet hours — hold non-urgent emails outside of work hours, deliver in a morning batch.

Acknowledgement-required distributions and safety notices ignore quiet hours — they're delivered immediately regardless.

Per-organisation email templates

Every notification email is rendered from a template. Templates are customisable per organisation:

→Add your logo, brand colours, and footer.
→Override the wording for specific notification types.
→Add a banner (e.g. "Notice: site shutdown for Easter long weekend").

The default templates ship with neutral, professional copy — most teams never touch them.

Deliverability

Email goes through the queue with retry, bounce, and suppression handling:

→Retry — transient failures (rate limits, temporary DNS issues) retry with exponential backoff.
→Bounce handling — hard bounces (invalid address) suppress the recipient and surface in the admin dashboard.
→Suppression list — recipients who unsubscribe, mark spam, or hard-bounce are added to the suppression list and excluded from future sends.

Two delivery backends are supported, picked per-organisation:

→AWS SES — recommended for any team sending over a few hundred emails per day. Uses your verified domain.
→SMTP — for teams with an existing relay or specific compliance requirements.

If you're seeing deliverability issues, check the suppression list first, then verify SPF / DKIM / DMARC for the sending domain.

In-app notification feed

The bell icon at the top of the dashboard shows recent notifications, grouped by recency and unread status:

→Click one to jump to the relevant record.
→Mark all as read with one click.
→Filter by type if the feed gets noisy.

The in-app feed is real-time when you're online — push updates land within seconds of the event.

When notifications go silent

If you're expecting a notification and it doesn't arrive, check in this order:

01Workflow rule log — did the rule fire?
02Suppression list — is the recipient suppressed?
03User preferences — has the recipient disabled this notification type or set quiet hours?
04Email deliverability — bounce, spam folder, DMARC failure?

The platform never silently drops a notification — every failure point is logged.