Shellius notifies people when something needs their attention: an access request waiting for review, a decision on their own request, access about to run out, a break-glass connection, or a posture finding. Notices appear in the portal, and the important ones are also emailed.
Required permissions
None. Every signed-in user sees their own notifications and nobody else's — there is no organisation-wide notification view.
Who receives a notice depends on the event: approvers are whoever the server's policy names as approvers, and posture recipients come from alert rules, which need posture.settings to edit.
What triggers a notification
| Event | Who is notified |
|---|---|
| An access request needs review | Every eligible approver for that request |
| A request is approved, including automatic approval | The requester |
| A request is denied | The requester |
| Access is about to expire | The requester, once per request |
| Access has expired | The requester |
| Access is revoked | The requester |
| Break-glass access is invoked | Everyone whose role holds access_requests.revoke_any |
| A posture finding opens or changes | Recipients of the matching posture alert rule |
Posture notices fire on transitions, not on every scan. A finding that stays open across hundreds of scans produces one notification, muted findings notify nobody, and recipients are limited to people who can see the affected server.
Read your notifications
- Open Notifications in the portal. The count beside it is your unread total, refreshed every 30 seconds.
- Use the filter to switch between All notifications and Unread only, or type in Search notifications....
- Select a notice to mark it read and jump to the request or finding it refers to, or choose Mark all read.
INFO
Notifications are a convenience, not the record. The audit log is the authoritative history of who asked for, approved, and used access.
Email
Some events are also emailed:
- Approvers get an email with a link straight to the request, so a production request does not wait for someone to open the portal.
- Posture alert rules can email their recipients as well as notifying them in the portal.
- Account mail — invitations, password resets and changes, email verification, email sign-in codes, SSO link approvals and account deletion — is always email, because the person may not be signed in.
Decisions on your own requests (approved, denied, expiring, revoked) arrive as portal notifications.
Email only goes out if delivery is configured. With no provider and no SMTP_* variables, Shellius runs in log-only mode: nothing is sent, and in-portal notifications keep working. See Email delivery.
TIP
If approvers say they never hear about requests, check Administration → Email first. A provider that is configured but failing does not fall back to anything else — the send fails and the reason is in the backend log.