Project Notifications That Do Not Become Noise

How Every Tool Gets Here

The sequence is always the same. A tool ships with generous notification defaults so new users don't miss anything. Users get buried. Rather than tune it - which means finding a settings page and making a dozen decisions - they turn notifications off entirely, or create a mail rule that files them unread.

Now the tool can't reach them at all. Someone is blocked waiting on an answer, the notification was sent correctly, and it landed in a folder nobody opens. Everyone concludes the tool is bad at notifications, when what actually happened is that a single on/off switch forced an all-or-nothing choice.

The Two Questions One Switch Can't Answer

Any notification worth sending has two independent properties:

• How much does this matter to me? Being assigned work matters. A comment on a task you're vaguely following usually doesn't.
• How urgently should it reach me? Some things justify interrupting you. Most are fine waiting until you next open the app.

A single switch collapses both into one decision, so you end up choosing between interrupting for everything and hearing about nothing. The fix is a grid: every event type gets its own row, and each row picks its channels independently.

Three Channels With Different Costs

In-app. Effectively free. It waits in the bell until you choose to look. There's almost no reason to disable in-app notifications for anything - the cost of a notification you don't need is one line you scroll past.

Email. Moderately expensive. It reaches you outside the tool, which is the point, but email is where notification fatigue is usually born. Reserve it for things worth pulling you out of what you're doing.

Push. Expensive. A browser notification interrupts you wherever you are. The test is genuinely high: would you want this to reach you while you were deep in something else? For most event types the answer is no.

A good starting configuration is in-app for everything, email for assignments and mentions, push for mentions only.

Separating Ownership From Interest

The deeper problem isn't channel routing - it's that most tools have only one way to be connected to a task: you're the assignee, or you're nobody.

That forces bad behaviour. People assign themselves things they aren't doing just to stay informed, or CC half the team into a comment thread because there's no other mechanism. FlowBoard splits it three ways:

• Assignment - "this is yours to do." One person. Ownership.
• Watching - "keep me informed." Any number of people. Ambient, and quiet by design.
• @Mention - "I need something from you specifically." A question that stays open until answered.

Once those are distinct, the notification settings can be too. Watched-task updates get their own row, so you can follow twenty tasks with in-app only and never be interrupted by any of them. That's what makes watching cheap enough to actually use.

Watching Notifies on Outcomes, Not Edits

A watch that pinged on every field change would be useless within a day. So watched tasks notify on four things: completed, blocked, sent for rework, and commented on.

Retitling a task, adjusting an estimate, adding a tag - none of that notifies anyone. Those are edits. The four events that do fire are the ones that change what someone else might need to do.

Being assigned a task starts you watching it automatically, which is almost always what you want, and you can unwatch without being silently re-added.

Mentions Need Tracking, Not Just Delivery

A mention is different in kind from every other notification: it's a person waiting for a reply. Delivering it once and forgetting about it is why "did you see my comment?" is the most common message in every team chat.

A mention inbox tracks state instead. Each mention stays open until it's resolved, the badge counts what's outstanding, and replying resolves it automatically - because answering the question is what "handled" means.

The discipline that makes this work is on the sending side: mention one person, not four, and ask something answerable. "@sam does this need a migration?" resolves in a minute. "@sam thoughts?" sits open for a week and eventually gets cleared without being answered, which is how the signal dies.

Honest Controls

A small thing that matters more than it sounds: some event and channel combinations don't exist. The weekly digest, for instance, goes to a workspace's Slack or Teams channel rather than to individuals.

FlowBoard shows a dash there rather than a switch. It would be easy to render a toggle that quietly does nothing, and users would flip it, assume it worked, and lose trust in every other setting on the page when it didn't. A control that isn't wired to anything is worse than no control at all.

The same principle applies to unsubscribing. The link in every notification email turns the email channel off durably - it isn't quietly re-enabled by a later preference change. In-app notifications continue, so nothing is lost; it just stops arriving in your inbox.

A Configuration That Holds Up

• In-app: on for everything. It costs nothing and means you can always reconstruct what happened.
• Email: assignments and mentions only. Both mean someone is expecting something from you.
• Push: mentions only, and only if you're the sort of person who'd want to be interrupted by a direct question.
• Watched tasks: in-app only. This is what lets you watch generously.
• Due date reminders: whatever channel you actually read in the morning. It's one digest a day, not one per task.

Then leave it alone for two weeks and adjust the one row that annoyed you most. Tuning everything at once produces a configuration you don't understand and won't maintain.

Summary

Notification overload isn't caused by too many notifications. It's caused by tools that can't tell the difference between "this is yours" and "this might interest you", and then offer a single switch to manage both. Give each event its own row, each channel its own cost, and mentions a state that clears when someone actually replies - and the inbox stops being something people mute.

Get started with FlowBoard, or read about async communication.

Frequently Asked Questions

How do I stop getting too many project management notifications?

Rather than turning everything off, set channels per event type. Keep in-app on for everything since it costs nothing, restrict email to assignments and mentions, and reserve push for direct questions.

What is the difference between watching a task and being assigned it?

Assignment means you're responsible for doing the work. Watching means you want to know how it turns out. Watching is deliberately quiet - it notifies only when a task is completed, blocked, sent for rework, or commented on.

Does FlowBoard support browser push notifications?

Yes, on a per-event basis. Push permission is granted per browser and per device, so enabling it on one machine doesn't enable it everywhere.

Why are some notification switches shown as dashes?

Because that event doesn't deliver on that channel. The weekly digest, for example, goes to a connected Slack or Teams channel rather than to individuals. A dash means the combination doesn't exist, rather than being switched off.

What happens if I unsubscribe from notification emails?

The email channel is turned off durably and won't be silently re-enabled. In-app notifications continue, so you don't lose anything - it just stops reaching your inbox.