Notifications

What gets sent

Notifications are events, not a feed of everything that happens. Each one exists because somebody needs to act or needs to know.

To employees: a week was published or changed in a way that affects them; their time-off request was approved or denied; a swap they are part of moved; an open shift they can claim was posted; their claim was approved, denied or assigned to them.

To managers: somebody requested time off; a swap is waiting on their approval; an open shift was claimed; the weekly briefing; the auto-draft finished seeding next week.

Notably absent: routine edits. A manager moving a shift within a draft week notifies nobody, because nobody has seen that week yet.

Channels

• In-app bell — every notification, marked read per person.
• Email — the ones worth interrupting somebody for.
• Slack or Microsoft Teams — the weekly manager briefing, via a webhook you configure once. It posts to a shared channel, so it fires once per organization rather than once per manager.

Native mobile push is not shipped yet; the mobile web app relies on email and the in-app bell.

Muting what you do not want

Preferences are per person and per type, so you can silence open-shift announcements without losing the message that says your time off was approved.

Muting a type silences both your email and your bell for it. It does not silence the team's Slack or Teams channel — that is a shared channel, and one person's inbox preference should not decide what the team sees.

How long they stay

Notifications are a working inbox, not a record. They are swept after roughly three months.

The permanent record of what happened is the audit log, which is a different thing with a different purpose: notifications tell people something is waiting; the audit log answers who did what, later.