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, and the mention also lands in their in-app feed. You can mention any Company Admin, Manager or User in the organisation. If they aren't on the project, you're warned first, and confirming gives them read-and-reply access to that one defect or thread.
→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.

The email to the trade

When a defect is issued to a trade, the email names the job the way a trade looks for it: the site address and location first, then the issue and photos, the job number and project, the room, the project coordinator to call, and who raised it. Sent to a named contact, it carries a link to reply without logging in, and asks the trade to attach photos of the finished work there.

→Your own standing clauses, sign-off and CC. Company Admins add them once in Settings › Email, under Trade Emails. Clauses print below the job details in the order you set. Leave everything empty and the email goes without them.
→Owner contact details are opt-in per project. By default the email names who raised the defect but never their email or phone. A project's settings can switch that on for trades, separately from the switch for the Defect Notification report.

A project can also hold the email until someone presses Send, and every email a defect sends is kept on its audit trail. Both are covered in Defects.

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.