Overview
Broadcast Messages allow administrators to communicate important information to users directly inside the application. Messages appear as banners across the entire system or within specific areas, making them ideal for maintenance notices, policy reminders, feature announcements, or critical alerts.
Broadcast messages are time-bound, context-aware, and auditable, ensuring the right message reaches the right users at the right time.
Multiple Messages
It is possible to have multiple broadcast messages active simultaneously. They will stack by start time (newest first).
When to Use Broadcast Messages
Broadcast messages are best suited for:
- Scheduled maintenance or outages
- Time-sensitive policy or compliance notices
- Facility-wide announcements
- Feature launches or changes in behavior
- Emergency or critical system alerts
They are not intended for one-to-one communication. For conversations or task coordination, use Requests and Comments instead.
Message Behavior at a Glance
| Capability | Description |
|---|---|
| Scope | Show on all pages or restrict to a specific path |
| Timing | Automatically appear and disappear based on start/end time |
| Severity | Visual emphasis using Success, Info, Warning, or Error |
| Visibility | Sticky (always visible) or dismissible |
| Formatting | Rich text with Markdown support |
| Audit | Full action history and dismissal tracking |
Creating a Broadcast Message
Message Content
The Message field supports Markdown and is the primary content users will see.
Good messages are:
- Clear and concise
- Action-oriented when needed
- Explicit about timing or impact
Example:
Scheduled Maintenance: Colabmacs will be unavailable on Saturday from 02:00–06:00 MST.
Please save your work ahead of time.Message Type
Each message has a Type, which controls its visual weight.
| Type | Intended Use |
|---|---|
| Success | Positive outcomes or completed changes |
| Info | Neutral or informational notices |
| Warning | Upcoming changes or important reminders |
| Error | Critical issues or outages |
Choose the least severe type that still conveys the importance of the message.
Display Path
The optional Path field limits where the message appears.
| Path Value | Result |
|---|---|
| (empty) | Displays on all pages |
/admin | Only admin pages |
/resources | Resource-related pages |
/resources/resource-slug | A specific resource page |
/trainings | Training pages |
/requests | Request workflows |
Paths automatically include all sub-paths.
Icons
Messages include an icon from the Material Design Icons set.
Icons are helpful when:
- Differentiating multiple messages
- Reinforcing severity (e.g., warning, construction)
- Improving scannability
Scheduling Visibility
Broadcast messages are always time-bound.
- Starts: When the message becomes visible
- Ends: When the message is automatically removed
This ensures outdated announcements never linger in the UI.
Best practice:
End messages shortly after they are no longer relevant.
Sticky vs. Dismissible
These two options control how users interact with the message.
Sticky
- Pins the message to the top of the page
- Cannot be scrolled away
Use for:
- Active incidents
- Mandatory notices
- System outages
Dismissible
- Allows users to close the message
Use for:
- Informational notices
- Feature announcements
- Non-critical updates
These options can be combined (e.g., sticky but dismissible).
Managing Existing Messages
Broadcast messages are managed from Settings → Broadcast Messages.
From the list view, administrators can:
- See which messages are active or expired
- Edit message content or timing
- Remove outdated messages
- Review dismissal and audit history
Expired messages automatically stop displaying but remain visible for audit purposes.
Dismissal Tracking
For dismissible messages, Colabmacs tracks which users have dismissed the message.
This allows administrators to:
- Confirm visibility of important notices
- Identify users who may have missed critical information
- Manually mark messages as dismissed if required
Audit & Accountability
Every broadcast message includes an Action Events history, capturing:
- Creation
- Updates
- Deletion
- Who performed each action
- When it occurred
This ensures transparency and supports operational accountability.
Example Configurations
System Maintenance
Type: Warning
Sticky: Yes
Dismissible: No
Path: (all pages)
Duration: 48 hours before → 2 hours after maintenanceNew Feature Announcement
Type: Success
Sticky: No
Dismissible: Yes
Path: (all pages)
Duration: 7 daysTraining Reminder
Type: Info
Sticky: No
Dismissible: Yes
Path: /trainings
Duration: 14 daysBest Practices
- Keep messages short and purposeful
- Avoid overlapping or excessive active messages
- Prefer warnings over errors unless the system is truly unavailable
- Always set realistic end dates
- Periodically review and clean up expired messages