Notifications and channels | Documentation

Performance Blocks generates a steady stream of activity — observations shared, summaries published, conversation replies, objective approvals, admin alerts. This article covers the notification types the platform produces, the channels it can deliver them through, the controls available to individual users and to org admins, and how to recover when notifications stop arriving.

It applies to both Team and Agentic plans. Slack and Microsoft Teams routing requires the relevant integration, which is an Agentic-plan feature; in-app and email notifications work on both plans.

Notification types

The platform sends notifications for events that the recipient has a stake in.

Event	Default audience	Default channels
Observation shared with you	The user the observation was shared with	In-app, email
Feedback request received	The user being asked for feedback	In-app, email
Conversation reply	The other participant(s) in the conversation	In-app, email
Summary published	The subject and their manager	In-app, email
Objective approval pending	The approver	In-app, email
Objective approved/declined	The objective owner	In-app, email
Cycle reminder	All eligible participants in the cycle	In-app, email
Henry suggestion (Agentic)	The user who triggered the flow	In-app
Mention in a note	The mentioned user	In-app, email
Admin alert (security)	All `org_admin` users	In-app, email
Billing alert	Account owner and `org_admin`	In-app, email

The "default channels" column shows the out-of-the-box delivery; users and admins can change this — see User-level controls and Org-level defaults.

Push notifications (mobile or browser) are not part of the default delivery set today. Notifications surface in-app the moment you open Performance Blocks and via email/Slack/Teams when you are away from the app.

Delivery channels

In-app

Always on. Every notification appears in the bell icon at the top right of the application. Unread counts surface there and on the side navigation. Marking a notification as read in one place clears it everywhere.

In-app notifications are not a per-user preference — they are the canonical record of activity for the recipient. The other channels exist to push that activity out to where the user already is.

Email

Email is on by default for every event in the matrix above. A user can disable email entirely per event type, or switch from immediate to digest mode (see Digest cadence below).

Sender address is notifications@performance-blocks.com (or your white-label domain if your account team has set one up). Bounced emails are tracked and a user with three consecutive hard bounces is flagged in the directory so admins can clean up the address.

Slack

Available on the Agentic plan once the Slack integration is connected. Connect under Settings -> Integrations -> Slack. Once connected:

Each user links their Slack account to their Performance Blocks account from Account settings -> Notifications -> Slack.
Notifications can be routed to direct messages from the Performance Blocks bot, to a per-team channel, or to a per-event channel.
The org admin sets the default routing under Settings -> Notifications -> Slack defaults.

If a user has not linked Slack, Slack-routed events fall back to email delivery for that user.

Microsoft Teams

Available on the Agentic plan once the Microsoft Teams integration is connected. Connect under Settings -> Integrations -> Microsoft Teams. Routing options mirror Slack: direct chat from the Performance Blocks bot, channel posts, or per-event channels.

Like Slack, an unlinked Teams account causes Teams-routed notifications to fall back to email.

User-level controls

Each user manages their own preferences at:

Account settings -> Notifications

The page shows every notification type as a row with one column per available channel (in-app, email, Slack if linked, Teams if linked). Toggle the channel on or off per event.

A user can also:

Set the email digest cadence (immediate, hourly, daily, off).
Set quiet hours to suppress non-urgent emails and chat-tool notifications during evenings, weekends, or a custom window.
Mark themselves as out of office with start and end dates, suppressing all non-urgent notifications until the end date.
Choose a default channel preference (e.g. "always prefer Slack DM if linked, otherwise email") that applies to any new event type added in the future.

Disabling a channel never disables in-app delivery. The bell icon always reflects the full activity stream so the user does not lose information when they next open Performance Blocks.

Localization

Email and chat-tool notifications are sent in the recipient's selected locale. The locale is set per user under Account settings -> Preferences and applies to the subject line, body, button labels, and date formatting. Notifications generated for new users (before they have signed in to set a preference) use the organization's default locale, which is set under Settings -> Preferences.

If your organization operates across multiple regions, leaving the org default at the most common locale and letting members override it gives the best experience. The bell icon in-app is always shown in the user's currently selected interface language.

Org-level defaults

Org admins set the defaults that apply to new members and any user who has not customized their preferences. Defaults live at:

Settings -> Notifications

For each event type, set the default channel(s). Save. The new defaults apply immediately to:

All members who have never touched their notification settings.
Newly invited members starting from their first sign-in.

Members who have customized any preference are not overwritten. The settings page surfaces a banner indicating that the org default has changed; the member can opt back into the new defaults with one click.

Org-level digest cadence

You can also enforce a maximum digest cadence (for example, "no immediate emails — daily digest only"). Setting an org-level cadence overrides any user choice that is more frequent than the org maximum. Users can still choose less frequent.

Org-level quiet hours

Org admins can set tenant-wide quiet hours that suppress non-urgent notifications outside business hours regardless of individual settings. Use this if your organization has a strict no-after-hours-pings policy. Critical security and billing alerts bypass quiet hours.

Email digest cadence

Each user can choose how often non-urgent emails are batched.

Cadence	Effect
Immediate	Every event triggers its own email as soon as it happens.
Hourly	Events from the past hour are batched into a single email at the top of the next hour.
Daily	One email per day at 8:00 in the user's local timezone with everything from the previous 24h.
Off	No email notifications. The bell icon is the only source.

Urgent events (admin security alerts, billing alerts) ignore the digest setting and are delivered immediately even when the user has chosen "Off."

If you want most users on a daily digest by default, set it as the org default. Users can opt to "immediate" individually if their work pace requires it.

Quieting notifications

There are three layers of quieting.

Quiet hours (recurring)

Account settings -> Notifications -> Quiet hours. Choose a daily window (e.g. 18:00–08:00) and which days it applies to. Inside the window, email and chat-tool notifications are deferred until the end of the window. In-app notifications are not deferred — they accumulate silently.

Critical events (security alerts, billing alerts addressed to the account owner) bypass quiet hours.

Out of office (one-time)

Account settings -> Notifications -> Out of office. Set a start and end date. While OOO:

Email is deferred to the end date.
Slack/Teams notifications are deferred similarly; the bot also surfaces an OOO note when other users mention you.
Conversation invitations and feedback requests show your OOO status to the requester so they can reschedule.

Per-event opt-out

Some events are noisier than others for some users. Disable them outright on the per-event row in Account settings -> Notifications.

Slack and Teams routing details

When the integration is connected and the user has linked their account, three routing modes are available per event type.

Routing mode	Where the notification lands
Direct message	Performance Blocks bot DMs the user.
Team channel	Posted in the channel the user has assigned for their team.
Event channel	Posted in a channel chosen specifically for that event type (e.g. `#perfblocks-feedback`).

Org admins set defaults; users override per event. The bot only posts to channels it has been explicitly invited to. If the bot has not been added to a routed channel, the notification falls back to direct message.

Notification content and privacy

Notification bodies are short summaries (the actor's name, the event type, the affected record's title) plus a deep link into the app where the recipient signs in to read the full content.

Sensitive content (the body of an observation, the rating in a peer review) is not included in the email or chat message itself. The recipient must sign in to read it.
Subject lines are written so they do not leak content to a phone lock screen preview ("Anika shared an observation with you" rather than "Anika rated your project: 'Needs improvement'").
Anonymous feedback notifications never include the author's name.

This default cannot be loosened — there is no setting to send full content over email, by design.

Troubleshooting missing notifications

When a user reports that notifications have stopped, work through the checks below.

1. Check in-app first

Open the bell icon. If the events are there but did not arrive over email/Slack/Teams, the issue is on the delivery side, not on the platform side.

If the events are not even in the bell, the user may not be on the recipient list (e.g. the observation was shared with someone else) or visibility rules excluded them.

2. Check delivery preferences

Account settings -> Notifications. Confirm the relevant channel is enabled for the relevant event type, and that quiet hours / OOO are not currently active.

3. Check email deliverability

Look in spam/junk and in any organization-level mail filter.
Check whether the email address is flagged as bounced (Settings -> Members -> [user]). A flagged address needs admin attention to clear once the user confirms it is correct.
If your IT team filters by sender domain, ensure performance-blocks.com (and the SPF/DKIM/DMARC records published for it) are allowed.

4. Check Slack / Teams link

Account settings -> Notifications -> Slack (or Teams). Re-link if the connection shows "Reauthorize required."
Ensure the Performance Blocks bot is a member of any channel the user has selected for routing.
For org-wide outages, an org admin can check Settings -> Integrations -> [Slack/Teams] for the integration's overall health.

5. Check digest cadence

If the user expected immediate emails but is on a daily digest, there is no missing notification — it will arrive at 8:00 the next day. Confirm cadence on the preferences page.

6. Check audit log

Settings -> Audit logs has entries for notification delivery for the past 90 days. Filter by the user and the event type. The log shows whether delivery was attempted and whether it failed (with reason).

Common patterns

A handful of patterns cover most reports of "notifications are broken":

A whole organization is missing email — usually a domain-level mail filter that recently tightened. Have IT allow performance-blocks.com and confirm SPF/DKIM/DMARC alignment.
A single user is missing email — usually a flagged bounce address or a personal filter rule.
Slack notifications are missing for one user — usually their Slack link expired after a workspace rotation; re-link from Account settings.
Notifications are arriving but appear delayed — check whether the user has a digest cadence set; immediate emails should arrive within a minute or so under normal conditions.

If the audit log shows the platform attempted delivery and the receiver shows nothing, the issue is downstream of the platform. If the audit log shows no attempt at all, the event either was suppressed by a preference or the event itself never fired (in which case look at the upstream feature, not the notifications system).

Email deliverability

For email-based notifications, a few infrastructure choices keep deliverability strong:

The sending domain has SPF, DKIM, and DMARC records published. Your IT team can verify them with any standard DMARC inspector.
Each notification email has a List-Unsubscribe header that points back to the in-app preferences page so receivers' mail systems treat the messages as transactional rather than promotional.
Bounce and complaint rates are monitored continuously; addresses with persistent hard bounces are suppressed and flagged in the directory.
A user's own email preferences (digest cadence, per-event toggles) are honored before a message is composed, so the platform does not rely on the receiver's filter to suppress unwanted mail.

If a member's email starts to bounce after a name change at your company, the most common cause is that the old address still exists as their Performance Blocks identifier. Update the email under Settings -> Members or have the user update their own profile.

Best practices

Set sensible org defaults early. Once a member customizes their preferences, your defaults no longer reach them.
Use a daily digest as the org default for most event types. It cuts inbox noise dramatically and people still see urgent items in-app.
Reserve immediate-email for two or three event types where speed matters (objective approval pending, mention in a note).
Configure org-level quiet hours if your organization has a policy on after-hours communication.
Keep one or two event-specific Slack channels (#perfblocks-feedback, #perfblocks-summaries) that interested users can join, rather than creating a channel per team.

Notification cadence by role

The right defaults differ by role. The configuration below is a sensible starting point that you can adapt.

Employees

Observation shared with you: in-app + immediate email.
Feedback request received: in-app + immediate email.
Conversation reply: in-app + immediate email (Slack DM if linked).
Summary published about you: in-app + immediate email.
Mention in a note: in-app + immediate email.
Cycle reminder: in-app + email.

Managers

Everything in the employee column, plus:

Direct report shared an observation: in-app + email (daily digest).
Direct report submitted a self-assessment: in-app + immediate email.
Approval pending on a direct report's objective: in-app + immediate email + Slack DM if linked.
Cycle reminder for any of your direct reports: daily digest.

Org admins

Everything in the manager column, plus:

Security alert (failed sign-in spike, unusual API key usage): in-app + immediate email + Slack channel if configured.
Billing alert (payment failed, seat overage): in-app + immediate email.
Subscription renewal reminders: weekly digest until renewal.
New member invited / accepted: daily digest.
Audit log export ready: in-app + email.

Notification rate limits

To prevent runaway loops or accidental spam, the platform applies internal rate limits per recipient per channel. If a single user would receive more than a few dozen notifications of the same type within a short window, the platform compresses them into a single summary notification ("12 new replies in #project-redesign") instead of sending each one. The bell icon retains the individual events so nothing is lost — only the email and chat-tool fan-out is compressed.

You will see compression most often when a Henry agent posts many updates to the same conversation, or when a large feedback request is fanned out and then quickly rescinded.

Mobile and push

The current product surface is a responsive web app that works in mobile browsers. There is no separate native mobile app and no push-notification channel today. For mobile members:

The mobile-web experience supports reading and replying to in-app notifications, recording observations, and participating in conversations.
Email and Slack/Teams (where linked) are the practical "away from desk" notification channels. Most users will see Performance Blocks activity through whichever of those they already monitor on their phone.
If your organization standardizes on a particular team-chat product (Slack or Teams), encourage members to link their account so notifications follow them naturally.

If a future native mobile app changes this, the channel matrix at the top of this article will be updated and an admin alert will surface in your tenant.

Notification API and webhooks

On the Agentic plan, notifications can also be delivered via outbound webhook to an HTTPS endpoint your team controls. This is the right path if you want to land the events in your own messaging product, ticketing system, or data warehouse.

Configure outbound webhooks at Settings -> Integrations -> Webhooks. Each webhook destination has its own signing secret, retry policy, and event-type filter. The body of the webhook is the same lean summary that the in-product notifications use — sensitive content is not included; the receiver dereferences a URL to load the full record under an authenticated session if needed.

Failed webhook deliveries are retried with exponential backoff for up to 24 hours, then surfaced as an admin alert.