Appearance
Notifications & Emails
Purpose: What the system sends, when, and to whom. There are around fifty emails and a resident push-notification pipeline with some non-obvious behaviour, so this is the map for "why did (or didn't) that message go out?"
Primary users: Support and delivery staff diagnosing missing messages; anyone changing a workflow that notifies people.
Three separate "notification" systems
"Notification" means three different things here. Don't conflate them:
- Resident push notifications to the mobile/web app (the main one, below).
- Everest dashboard alerts, in-app flags for staff about listing/sync problems (see Everest).
- Slack alerts to the team when a unit is updated.
Resident push notifications
When something happens on a tenancy, the system records a notification and pushes it to the resident's registered devices (via Firebase).
Key rules worth knowing:
- Push is in "dry-run" mode by default. Unless it's turned on for the environment, nothing is sent, and there's no error to show for it, so in most environments pushes don't go out at all. This is the first thing to check when a push "didn't arrive".
- Residents can opt out per type, so a resident who has disabled a category won't receive it.
- Categories map to a smaller set of app message types. There are ten internal categories (General, Payment, Document, Building, Support, Renewal, Section 13, Vacating notice, Referral, Inspection) mapped onto seven message types the app understands; anything without its own type shows as a general message.
- Dead device tokens are cleaned up automatically, and if delivery fails the admins are emailed.
What triggers a resident notification:
| Trigger | Category |
|---|---|
| Renewal reached (scheduled) | Renewal |
| Mid-tenancy or check-out inspection due (scheduled) | Inspection |
| Fixflo repair status changes | Repair update |
| Admin sends a building-wide message | Building |
| Section 13 notice served | Section 13 |
| Support submission status changes | Support |
| Qube transaction raised | Payment |
| Referral move-in | Referral |
| Staff send one manually (Portal or the app) | Any |
Emails
The system sends around fifty emails across the apps. The full copy lives in editable templates (the database-backed templates and the Confluence Email Catalogue); this is the trigger-and-recipient map.
Resident-facing:
| Sent when | To | |
|---|---|---|
| Tenancy invite | A customer is invited to the resident app | Resident |
| Section 13 notice (letter and PDF variants) | A rent-increase notice is served from the Rent Review tracker | Every tenant on the tenancy |
| Document uploaded / deleted / download link | Documents change or a full download is requested | Resident |
| Support reply / reopened | Staff reply to a support request | Resident |
| End of tenancy confirmation | A resident gives notice | Resident |
| Direct debit invite / reminder / ending / renewing | Direct-debit lifecycle | Resident |
| Social account link | A resident links a social login | Resident |
Staff-facing:
| Sent when | To | |
|---|---|---|
| Deal sheet saved / locked-deal-sheet updated | Deal-sheet activity | Lease officer |
| Bulk import completed | A deal-sheet CSV import finishes | Uploading admin |
| Viewing attendance / action required | Scheduled viewing follow-ups | Staff |
| Reservation link / affordability / fee paid | Reservation activity | Customer or admin |
| Reposit created / failed | Auto-created deposit-replacement policy | Admin |
| Move-out completed / date changes | Move-out activity | Staff |
| Renewal entered tracker | A tenancy enters Rent Review | Staff |
| End of tenancy notice | A resident gives notice | Staff |
| Inventory Hive check-in / interim / check-out reminders | Scheduled inspection reminders | Staff |
| Submit-to-Qube / referral move-in / payment-match failed | Qube and payment events | Admin |
| Property archived / decommissioned / restored (Everest) | Property lifecycle jobs | Admin |
| Tableau account / groups / credentials (backend) | Tableau provisioning jobs | Ops |
Building notifications
An admin can send a building-wide message, filtered by building, block, floor, apartment, pets or vehicles. Each matched unit gets a push, and optionally an email to the tenants. (Note: despite older plans, there is no feature flag retiring this in the current code; it's live.)
Where the detail lives
Email copy is in the database-backed mail templates (editable per operator in Olympus Frontend) and the Confluence Email Catalogue. The Automation page lists the scheduled jobs that send many of the above.