User guide
Notifications
Looking for what it does rather than how to use it? Read the Notifications overview .
What it is
Solidlio tells you when something in your work needs attention: a ticket lands in your queue, an SLA is about to run out, a change is waiting on your approval, a warranty expires next month. Each of those writes one notification to you, and that notification is delivered in the app in real time and, if you have turned it on, as a push notification to your browser and phone.
Notifications are not email. Ticket replies, invoices, quotes, password resets and every other message that leaves the platform are sent by the email service and are documented separately. This guide covers the in-app inbox, the browser and mobile push channels, and the preferences that gate them.
Concepts
| Noun | What it is |
|---|---|
| Notification | One message addressed to one person. Has a type, a title, a body, an optional deep link, an optional tenant, and a read flag. Id prefix ntf. |
| Notification type | The event that produced it — TICKET_ASSIGNED, CHANGE_APPROVAL_REQUIRED, LICENSE_EXPIRING. 59 exist; 42 of them are yours to switch on and off. |
| Preference | Your own channel switches, your enabled-type allowlist, your quiet-hours window and your mute expiry. One row per person. Id prefix nfp. |
| Channel | Where a notification is delivered: in-app (the bell and the centre), browser push, mobile push. |
| Quiet hours | A daily window, in your own time zone, during which push is held back. The notification is still recorded and still appears in the inbox. |
| Mute | A temporary stop on in-app and push delivery, up to one week. Notifications are still recorded. |
| Push subscription | One browser’s registration for web push. Id prefix psh. Deleted automatically when the browser reports it as gone. |
Notification types
Types are grouped into eight categories.
| Category | Types |
|---|---|
| Tickets & support | TICKET_CREATED, TICKET_ASSIGNED, TICKET_UPDATED, TICKET_COMMENT, TICKET_RESOLVED, TICKET_SLA_WARNING, TICKET_SLA_BREACH, TICKET_DE_ESCALATED, TICKET_UNASSIGNED_TIMEOUT |
| Change management | CHANGE_SUBMITTED, CHANGE_APPROVAL_REQUIRED, CHANGE_APPROVED, CHANGE_REJECTED, CHANGE_SCHEDULED, CHANGE_IMPLEMENTING, CHANGE_COMPLETED, CHANGE_FAILED, CHANGE_EMERGENCY_INVOKED, CHANGE_PIR_OVERDUE, CHANGE_RETRO_APPROVAL_DUE, CHANGE_MAINTENANCE_WINDOW_START, CHANGE_MAINTENANCE_WINDOW_END, CHANGE_MSP_ESCALATED |
| Projects & tasks | PROJECT_TASK_ASSIGNED, PROJECT_TASK_DUE, PROJECT_MILESTONE_DUE, PROJECT_STATUS_CHANGED |
| Calendar | CALENDAR_EVENT_INVITED, CALENDAR_EVENT_UPDATED, CALENDAR_EVENT_CANCELLED, CALENDAR_EVENT_REMINDER |
| Billing | SUBSCRIPTION_UPGRADED, COMMISSION_EARNED |
| Assets & licences | ASSET_WARRANTY_EXPIRING, ASSET_EOL_APPROACHING, LICENSE_EXPIRING |
| MSP co-management | MANAGEMENT_INVITE_RECEIVED, MANAGEMENT_REQUEST_RECEIVED, MANAGEMENT_LINK_ACCEPTED, MANAGEMENT_LINK_DECLINED, MANAGEMENT_ACCESS_ENDED |
| System | SYSTEM_ANNOUNCEMENT |
TICKET_ESCALATED is not in this list on purpose. Escalations are dispatched with the preference check skipped, so a switch for them would be a control that does nothing; they are always delivered.
Roles and permissions
Notifications are addressed to a person, not to a role. Everything about your own inbox and your own preferences is available to every signed-in user in every portal, from CUSTOMER upward — reading and muting your own notifications is not an administrative act.
| Action | Who can do it |
|---|---|
| Read, mark read, delete your own notifications | Any signed-in user |
| Change your own preferences, quiet hours, mute | Any signed-in user |
| Register a browser or mobile push subscription | Any signed-in user |
| Read another person’s notifications | Nobody, at any role |
| Read platform-wide event-stream statistics | platform administrator |
Every read, mark-read and delete is matched on (id, personId). Supplying another person’s notification id returns 404 Notification not found, not a 403 — the id is not confirmed to exist.
Walkthroughs
Read and clear your notifications
- The bell sits in the header of every portal. The badge counts unread items and updates the moment one arrives; above 99 it reads
99+. - Click the bell for the ten most recent. Hovering a row reveals Mark as read and Delete.
- Click View all notifications (or the gear) to open the notification centre at
Notificationsin your portal —/org/notifications,/msp/notifications,/user/notificationsor/platform/notifications. - In the centre, switch between All and Unread, page through 20 at a time, or press Mark all read.
- Clicking a notification opens what it is about and marks it read. If your portal has no page for that object — a change request seen from the customer portal, for example — the row stays as text rather than linking to a page you cannot open.
Choose what you are notified about
- Go to Notifications → Preferences in your portal.
- Under Channels, switch In-app and Push on or off.
- Under What you get notified about, expand a category and switch individual types. Enable all and Disable all act on the whole category.
- Changes save as you make them. A type you switch off is not created at all — it will not appear in your inbox later.
Set quiet hours
- Notifications → Preferences → Quiet hours.
- Set Start, End and your Time zone. A window that crosses midnight (
22:00–08:00) is handled as one overnight block. - Inside the window, push is held back. The notification is still created and still appears in the inbox, so nothing is lost.
- Clear either time field to switch quiet hours off.
The window is evaluated against your stored IANA zone, not the server’s clock, so 22:00–08:00 in America/Toronto means those hours in Toronto wherever the service happens to be running.
Mute everything for a while
- Press Mute at the top of the notification centre.
- Pick 30 minutes, 1, 4, 8 or 24 hours, or 1 week. The maximum the service accepts is 10 080 minutes.
- While muted, in-app and push delivery both stop. Notifications are still recorded and appear when you come back.
- Press Unmute to end it early.
Turn on browser push
- Notifications → Preferences → Channels → Push.
- The browser asks for permission. Grant it.
- Switching Push off removes the browser’s subscription as well as the preference, so the browser stops holding a registration nothing will use.
Turn on mobile push
- Sign in to the Solidlio app on iOS or Android and accept the notification permission prompt.
- The app registers its Push notifications token against your account automatically, on every sign-in and on every session restore.
- More → Settings → Notifications in the app carries the same channel switches, category switches and quiet-hours window as the web.
- Signing out unregisters that device’s token.
Push messages carry an Android notification channel chosen from the type: SLA breaches and escalations go to critical_alerts (maximum importance, bypasses Do Not Disturb), tickets to tickets, approvals to approvals, everything else to standard_alerts or general. Change-approval notifications that carry an approval id additionally get iOS Approve / Reject action buttons. The app badge is set to your live unread count on every push.
Configuration
Per person
| Setting | What it does | If unset |
|---|---|---|
inAppEnabled | Whether new notifications are pushed to the open event stream | On |
pushEnabled | Whether browser and mobile push are attempted | Off |
emailEnabled | Whether product and setup-reminder emails are sent | On |
enabledTypes | Allowlist of manageable types. A type not on it is never created | All 42 manageable types |
quietHoursStart / quietHoursEnd | Daily window, HH:mm, in which push is held back | No window; push is never held back |
timezone | IANA zone the quiet-hours window is evaluated in | America/Toronto |
mutedUntil | Instant until which in-app and push delivery stop | Not muted |
emailEnabled gates product and setup-reminder mail only. It does not gate transactional mail — ticket replies, invoices, quotes, password resets and verification messages are sent regardless, because they are the answer to something you did.
Per queue (ticket queues)
Three switches on a ticket queue decide whether its members are told about tickets in it. They are set under Settings → Queues.
| Setting | What it does | Default |
|---|---|---|
notifyOnNewTicket | Tell active members when a ticket enters the queue | On |
notifyOnSlaWarning | Tell active members when a ticket’s SLA is at risk and when it breaches | On |
notifyOnUnassignedTimeout | Tell active members when a ticket has sat unassigned past the timeout | Off |
Per deployment
| Variable | What it does | If unset |
|---|---|---|
VAPID_SUBJECT | Contact address push providers use to reach you about a misbehaving sender | mailto: the support address for the configured email domain |
SSE_HEARTBEAT_INTERVAL | Milliseconds between keep-alive frames | 30 000 |
SSE_RETRY_INTERVAL | Reconnect delay the server suggests to EventSource | 3 000 |
Plan tiers
Notifications are not tier-gated. Every capability in this guide — the inbox, the event stream, preferences, quiet hours, mute, browser push and mobile push — is available on every plan.
Troubleshooting
“I am not getting notifications for X.” Open Notifications → Preferences and check the category. A type switched off is never created, so there will be no record of it in the inbox either. If the type is on, check whether you are muted (the banner at the top of the centre says so) and whether the notification is for a queue whose notifyOnNewTicket is off.
The bell badge is stale. The web app polls the unread count every 30 seconds and the list every 60 seconds, so a stale badge corrects itself within a minute. It also corrects immediately on any reconnect of the event stream, which sends a sync frame carrying the authoritative count.
Rotating the pair invalidates every existing browser subscription, so treat it as long-lived.
This browser does not support push notifications. The browser has no serviceWorker or no PushManager. Safari requires the site to be installed to the home screen on iOS.
Push stopped arriving on one browser. A 410 Gone from the push provider deletes that subscription automatically. Turn Push off and on again in preferences to create a fresh one.
Five consecutive failures of any other kind also deactivate it. Signing in again re-registers the token and clears the failure count.
Validation error on mute. The field is durationMinutes, between 1 and 10 080. duration is not accepted.
A notification links somewhere I cannot open. Links are stored portal-neutrally and qualified against your portal when rendered. If your portal serves no page for that object, the row renders as plain text rather than as a link to a 404.
Limits and known behaviour
- Quiet hours gate push only. In-app delivery and the inbox are unaffected — the window is about not being interrupted, not about not being told.
- Mute gates in-app and push. Notifications are still created and are all waiting when the mute expires.
- A disabled type is never created. There is no hidden archive of notifications for types you switched off.
- Escalations ignore preferences.
TICKET_ESCALATEDand platform operator alerts are dispatched with the preference check skipped, and are delivered on every channel you have enabled. - The event stream is not a durable queue. It replays nothing. Anything created while you were disconnected is picked up by the
syncframe on reconnect and by the polling fallback, not by replay. - The mobile app has an in-app inbox. It filters unread items, marks all read, deletes an item and routes supported notification types to their real portal destination. The
In-appswitch in mobile settings governs the same creation preference the web reads. - List pages are capped at 100 rows. A larger
limitis clamped. - Bulk internal dispatch is capped at 1000 entries per request.
- Notification bodies are plain text. No markup is rendered.