How Notifications Work

Boarbs has two separate notification paths:

• an in-app inbox for organization members
• post-based emails for subscribers

The inbox is workspace-wide. Subscriber emails only go to people following a specific post.

In-App Inbox for Organization Members

Every organization member has their own inbox in the app. New notifications stay unread until the member opens them or selects Mark all as read.

The inbox supports these events:

All four event types are on by default. Each member can open the inbox settings and turn individual event types on or off for themselves.

The in-app inbox is only for organization members. Public voters do not receive inbox notifications, and internal comments do not create inbox notifications.

The Subscriber Email Rule

When Boarbs processes a notification event, it emails subscribers on that post except the person who caused the event.

Subjects include the real post title. They do not leave {postTitle} or similar placeholders unreplaced.

Every outbound email also includes a Feature board powered by Boarbs footer that links to https://boarbs.com, unless a Pro workspace turns on Remove Boarbs branding. See Email Footer and Branding.

So the actor does the action, everyone else following that post gets the update.

How Someone Becomes a Subscriber

There are three main ways someone becomes subscribed to a post:

This is why voting is not only prioritization. It also opts the user into updates for that post.

Commenting Is Not the Same as Subscribing

Public comments can trigger email notifications to current subscribers.

But creating a comment is not the same as automatically subscribing the commenter.

If you want someone to keep receiving updates, they should vote or explicitly subscribe.

Events That Send Email

Boarbs currently sends subscriber emails for these post events:

Moving a post into a completed status category is special because it also counts as a normal status change.

Merge emails go to creators and subscribers of both the surviving post and the merged-away post. Duplicates are removed, and the person who performed the merge is not emailed. Unmerge does not send this email.

Marking a post as spam is not a subscriber event. If the operator chooses to inform the author, only the author receives a closed-post note. That note never says the post was marked as spam.

Changes That Stay Silent

These changes do not currently send subscriber emails by themselves:

• editing the title
• editing the description
• changing the ETA
• changing the assignee
• editing internal notes
• changing tags
• changing roadmap configuration
• changing board or workspace settings

That is why updating metadata alone does not “publish an update” in the way some teams expect.

Internal Comments vs Public Comments

Only public comments are part of the subscriber-facing update flow.

Internal comments are for team collaboration and should not be treated as customer-facing updates.

Why Someone Did Not Receive an Email

If a user expected an email and got nothing, check these in order:

1. they were actually subscribed to that post
2. they were not the person who made the change
3. the change was one of the email-triggering events
4. the comment was public rather than internal

If you self-host Boarbs, also confirm notifications are enabled in configuration.

Recommended Team Rules

Good teams stay consistent with these habits:

• use status changes for real milestones
• use public comments when context matters for followers
• move to a completed category only when the work is truly done
• do not assume ETA or assignee edits will notify customers

If You Need Release Notes

Changelog is a separate module for published entries on the portal, widget, embed, and the public list (GET /changelog/public). It does not send subscriber emails by itself.

The practical workflow today is:

1. move the post to the right status
2. leave a public comment with the user-facing context
3. make sure the roadmap reflects the same story
4. create a Changelog Draft in the workspace (or use the optional Complete / AI path), then Publish when you want an in-product release note

Next Steps

• Publish an Update — Turn this model into a consistent team workflow
• Permissions and Visibility — Separate public updates from internal discussion
• Troubleshooting — Debug missing emails and subscription confusion