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.

A handful of emails sit outside the rules engine, because they're mechanics rather than policy:

→@mentions. Mention a colleague in a defect note or a correspondence post and they're emailed. Email only, in this version — the mention doesn't also raise an in-app notification.
→Set a password / reset a password. The link is valid for a limited window and is single-use.
→Sign-off requests on an issued-to assignment, sent to the nominated approver.
→Correspondence invitations and replies, sent to external participants with a link that opens the thread without a login.

Per-user preferences

Each user sets their own digest cadence per organisation — daily, weekly, or off. It's the one preference that travels with the person rather than the workspace: if you work across two builders' orgs, you can take a daily digest from one and a weekly from the other.

Digest cadence governs the rolled-up mail — overdue defects, weekly activity. Event mail that exists to be a receipt (an assignment landing with a trade, an acknowledgement-required distribution) always sends immediately and is never batched.

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.

Email sends through a single transactional provider on a verified sending domain, so SPF, DKIM and DMARC are configured once rather than per organisation.

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?
03Digest cadence — is the recipient on a daily or weekly digest, so it's queued rather than missing?
04Email deliverability — bounce, spam folder, DMARC failure?

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