Announcements, notifications, and communication

Academia is not only a workflow tracker. It is also a communication layer. The platform uses announcements, notifications, messages, and realtime updates to keep the department moving when proposals are submitted, milestones change, evaluators fall behind, or defense activity gets closer.

Why this page matters

The current docs already mention notifications in proposal review, milestone review, staff oversight, and several role pages. The frontend and backend also show dedicated message surfaces, notification delivery, push support, and socket-based updates.

This page brings those pieces into one operating model.

Fastest route through this guide

1. Read Communication layers in the product to understand the major channels.
2. Read Operational use by phase to see when each channel matters most.
3. Read Realtime and delivery model to understand how updates reach users.
4. Continue to Staff oversight and assignment if you want the operational side of reminders and follow-up.

Communication layers in the product

The current product behavior points to four main communication layers.

1. Department-wide announcements

Announcements are the broadest communication surface.

Typical use:

• sharing department-wide reminders
• publishing workflow deadlines or readiness notices
• keeping students and staff aligned when schedules or policies shift

The role pages already show announcement access in department-head, coordinator, advisor, and student workspaces.

2. Workflow notifications

Notifications are event-driven system signals tied to state changes.

Current documented examples already include:

• proposal submission notifications to coordinators and department heads
• milestone approval or progress notifications for students
• evaluator reminder behavior in staff oversight flows
• backend-emitted group-review and proposal-review notifications

These are not general messages. They are workflow events that tell the next owner to act.

3. Direct messages and role communication

Several role guides already include message surfaces.

Typical use:

• coordinator follow-up with evaluators or committee participants
• advisor and student communication around project work
• role-specific operational messaging tied to active projects and review items

This layer matters because academic workflows often need contextual follow-up, not just automated alerts.

4. Realtime collaboration and session channels

The current frontend and backend also point to a stronger realtime layer.

Current examples include:

• notifications socket integration
• chat socket integration
• video or call-oriented collaboration surfaces referenced in the product repos

This is the layer that lets the platform feel live rather than only request-response driven.

Operational use by phase

Each phase of the lifecycle relies on communication differently.

Phase	Strongest communication need	Typical channel
Onboarding and setup	rollout guidance and access readiness	invitations, announcements, department notices
Group and proposal stage	submission visibility and review handoff	proposal notifications, role messages
Milestone stage	feedback loop and approval awareness	notifications, advisor-student messages
Evaluation stage	assignment follow-up and review readiness	coordinator reminders, evaluator messages, reports
Defense stage	schedule clarity and committee alignment	announcements, schedule notices, direct communication

Announcements versus notifications

These two layers should not be documented as the same thing.

Announcements are broad communications meant for a department or large audience.

Notifications are event-driven signals tied to a concrete workflow state change.

The difference matters in practice:

• use announcements when the department needs one shared message
• use notifications when a system event tells a specific user or role to do the next action

Realtime and delivery model

The current frontend derives a socket origin from NEXT_PUBLIC_API_BASE_URL for realtime behavior.

The documented realtime examples already include:

• notifications socket integration
• chat socket integration

The socket layer authenticates with:

• accessToken
• tenantDomain

This keeps the realtime channels aligned with the same tenant-aware context used by the REST client.

The backend-facing notification family also already includes push-oriented behavior such as:

• GET /notifications/push/vapid-public-key
• push subscription endpoints under /notifications/push

Practical communication model for staff

The most useful way to describe communication ownership is:

• department heads use announcements and oversight messages to keep the department aligned
• coordinators use reminders, status follow-up, and operational communication to keep reviews moving
• advisors use messages and review feedback to keep project delivery healthy
• students rely on notifications, messages, and announcements to know what changed and what to do next
• evaluators and committee members rely on reminders, schedules, and role messages as the defense stage approaches

Common mistakes to avoid in the docs

• Do not collapse announcements, notifications, and messages into one generic term. They serve different purposes.
• Do not describe notifications as only UI decoration. They are workflow handoff signals.
• Do not document realtime behavior as frontend-only. The tenant-aware socket and backend event model both matter.
• Do not ignore defense-stage communication. Late-stage coordination is one of the strongest reasons this layer exists.

Best page after this one

If you want to do next...	Go here	Why
Follow the staff side of reminders and intervention	Staff oversight and assignment	It shows how communication is used to keep assignments and evaluations moving.
Follow the proposal-stage notification flow	Proposal review and approval	It shows how notifications trigger the next review owner.
Follow the milestone-stage feedback loop	Milestone delivery and advisor review	It shows the advisor-student review cycle that generates many communication events.

Best next reads

• Staff oversight and assignment
• Proposal review and approval
• Milestone delivery and advisor review