Notifications
How in-app notifications surface crewing events across the office console and seafarer portal.
SeaSquad CMS includes an in-app notification feed that surfaces relevant events to the people who need to act on or be aware of them, inside the console and portal they already work in.
Where notifications appear
Notifications appear in two places, matching two of the product's zones:
- Office console — a notification indicator for signed-in office staff, surfacing events relevant to their work in the crewing office.
- Seafarer self-service portal — a notification area for a signed-in seafarer, surfacing events relevant to their own record.
The public careers site does not have a notification feed — applicants are reached by email instead, not through an in-app feed.
What a notification looks like
Each notification carries a category, a priority, a title, a short message, and — where relevant — a link to the specific record it concerns, so acting on it is a single click from the notification itself. A notification also records what it relates to (for example, a specific crew member or document), which is what allows notifications to be automatically resolved once the underlying situation is addressed.
Categories in use today cover system-level notices, crew record events, crew document events (such as an approaching expiry), and recruitment events. This set is expected to grow as more of the product's workflow areas come online.
Read and unread
Every notification has a status: unread, read, or archived. Unread notifications are what a badge count or indicator reflects; opening or acknowledging a notification marks it read. Notifications are not deleted outright — read notifications are retained for a period before being archived, and archived notifications are eventually cleared out automatically, so the feed reflects recent, relevant activity rather than accumulating indefinitely.
A seafarer only ever sees notifications addressed to them. Office-only details behind a notification — for instance, internal references used to route the item — are not exposed through the portal feed even when the underlying event also generates an office-side notification.
How notifications are kept relevant
Notifications are generated by the system in response to specific events in the underlying data — a crewing action, a document nearing expiry, a recruitment step — rather than being something a user posts directly. This keeps the feed tied to real, actionable events rather than becoming a general messaging channel.
Where the same underlying event could otherwise generate duplicate notifications — for example, if a background check runs more than once — the system is designed to avoid sending the same notification twice for the same event.
Staying current without refreshing
Within the console and the portal, the notification feed keeps itself up to date automatically while a user is signed in, so a new notification becomes visible without the user needing to manually refresh the page.