Notifications

The Notifications section is a per-user preference panel. Each toggle saves immediately, there is no Save button. It has two parts: Delivery, where notifications reach you besides the bell, and Events, a matrix of every notification kind against every channel.

Delivery channels

• In-app: every kind whose In-app toggle is on shows up in the topbar bell (the badge updates live) and on the /notifications page.
• Email: goes to the address you sign in with, shown in the Delivery section. If the server has no email provider configured, the section says so and the Email column is switched off.
• Microsoft Teams: goes to a Teams webhook you connect yourself (below). Until you connect one, the Teams column is switched off and nothing is sent.

Connecting Microsoft Teams

Teams delivery is personal: each person connects their own webhook, and only their own notifications are posted to it.

Teams delivery is temporarily paused while ProductOS waits for a Node.js security fix. Until it resumes, Connect and Send test say so, nothing is posted to Teams, and in-app and email notifications deliver as usual. Connected webhooks stay saved.

1. In Teams, open the Workflows app and pick the template Send webhook alerts to a chat (posts to a chat with you) or Send webhook alerts to a channel (posts to a channel you choose).
2. Finish the template's setup and copy the webhook URL it shows.
3. In ProductOS, open Settings → Notifications, paste the URL under Microsoft Teams and select Connect.

ProductOS posts a test card to check the URL and saves it only if Teams accepts the card. Only Teams webhook hosts are accepted (*.logic.azure.com, *.api.powerplatform.com and the older *.webhook.office.com). The URL is stored encrypted and never shown again; the section shows only its host.

Once connected you can Send test, Change the URL or Disconnect. If a delivery fails (for example, the workflow was turned off in Teams), the section shows the last error and when it happened. Disconnecting keeps your per-event Teams choices for when you reconnect.

Each notification arrives as a card with the workspace and event name, the title, a short summary, and an Open in ProductOS button. A status or target date change adds a row with the old and new value, for example Status: Discovery → In Progress, followed by the same details rows an email shows.

What a notification says

The title names who acted and the item they acted on, for example Grace Hopper moved WRK-000123 to In Progress or Grace Hopper mentioned you on THM-000012. Changes made by automation (a scheduled check, GitHub) leave the person out, and a merged pull request names the GitHub account that merged it.

Emails and Teams cards add a details block under the summary. In email each value looks as it does in the app: statuses and urgency are colored pills, and items, products, modules and people are outlined pills with the item's ID. Comments and Claude Code questions show as quotes.

• the item, with its sequence id and name, when the summary is something else (a comment, a pull request's title, a session's question)
• the item's product and module, where it has them
• for Work: its status and target date, unless the notification is about that change, and its Lead where it helps (status, date and assignment changes, due soon and overdue)
• for pull requests: the number and repository
• for new feedback: its product, module, urgency and segment

Quick actions

In the bell and on the Notifications page, a notification carries buttons for what you would most likely do next, so you can act without opening the item. They are judged on the item as it is now: Start is gone once the Work has started, and Apply once the proposal is decided. Doing one marks the notification read, and a change you can take back shows Undo.

Every notification also has two buttons that show on hover: mark read or unread, and turn this kind off in the app (the in-app toggle below; email and Teams stay as they are). Repository sync failed and my role changed always show in-app, so they have no turn-off. A button shows only when your role and function let you make the change.

On the Notifications page, J and K move between notifications (or point at one), Enter opens it, R replies or answers, U marks it read or unread, and 1 to 3 press its first three buttons. See Keyboard shortcuts.

Kinds

Toggle rows are grouped by category. The person who made a change is never notified of their own change, and team members on the roster without a ProductOS sign-in receive nothing.

• Features (sent to the feature's Lead and assignees; status, target date and comment notices also reach its followers):
  • assigned to me (made Lead or added as an assignee), unassigned (no longer Lead, or removed as an assignee)
  • status changed, target date changed (the bell, the Notifications page and the email show the old and new status as pills, and dates as 2026-Oct-31)
  • due soon (two days before the target date) and overdue (the day after it passes), unless the feature has shipped or been dropped
  • blocking feature shipped (a feature with a blocks dependency on yours shipped)
• Initiatives: initiative assigned to me (you were added to an initiative)
• Claude Code: Claude Code needs an answer (a session asked a question and is waiting), Claude Code session finished (it succeeded, failed or was cancelled). Sent to the person who started the session and the feature's Lead and assignees.
• Code: PR linked to my feature (from the GitHub webhook, the Documents section, MCP or Copilot), PR merged for my feature
• Sprint: sprint started, sprint ended (to everyone in the workspace)
• Releases: release scheduled this sprint (sent when a sprint starts, for each release dated inside it that isn't published or shipped yet), release published (to everyone in the workspace)
• Workspace:
  • repository sync failed: owners and admins only. In-app is always on; email and Teams are your choice. A connection that keeps failing sends at most one notice a day while the last one is unread.
  • member joined: owners and admins, when someone accepts an invite
  • my role changed: always on in-app
• Comments: mentioned in a comment, reply to my comment, comment on my feature or feedback (a comment on a feature you lead, are assigned to or follow, or on feedback you follow, unless a mention or reply notice already told you)
• Feedback: feedback linked to my feature, new feedback from outside (owners and admins; feedback from the widget, the public portal or the Feedback API), followed feedback status changed
• Following: added as a follower (someone else made you a follower of a feature or a piece of feedback)
• Connectors: connector needs a reconnect (a Claude or MCP client connected as you is using an older ProductOS tool list; see Keeping the connector up to date)

Kinds added later start with sensible defaults; you don't need to revisit this page after an update.

Background jobs

Three daily background jobs run behind this page:

• Sprint boundary: sends the sprint started / ended notifications at the rollover, and the release scheduled this sprint notices.
• Feature deadlines: sends the due soon and overdue notices. Dates are compared in UTC.
• Retention: deletes in-app notifications older than 90 days that you've already read; unread rows stay until you read them.

Defaults

Teams defaults apply only once you connect Teams.

The connector notice arrives at most once per connector version, and its email at most once in any 20 hours however many versions ship; a newer notice marks the older one read.

Persistence

Only your explicit overrides are stored, one row per event and channel; anything you haven't touched follows the defaults above. The Teams webhook is stored per person and workspace.

Related

• Account: the email address notifications are sent to