Notifications

A platform that does as much on your behalf as Disco Parrot does has to tell you when something happens. An agent finishes a task you set running. A plan you own moves to blocked. A teammate assigns you an initiative. You do not want to sit and watch for any of it, and you do not have to: notifications are how the platform reaches you when something you watch or own changes, so you can keep working and still know where things stand.

This page is about that system end to end. The bell in the top bar and the inbox behind it, where notifications land and you read them. The rule for who gets notified about a given change. The categories you tune and the channels they reach you on. The three layers of preference that decide what you actually receive, including the one a workspace can set for everyone. And the quiet by design: the rule that keeps your inbox to the changes a person would actually want to know, leaving out your own actions and an agent's routine edits. Your inbox is at Settings → Notifications, your preferences a click further at Settings → Notifications → Settings, and the bell is everywhere.

The bell and the inbox

The fastest way to see what is waiting is the bell in the top bar, to the left of the Settings shortcut and your account menu. It carries a count of notifications you have not yet seen, and the count is the whole point: a number on the bell means there is something new, no number means there is not. Click it and a flyout opens, headed Notifications, with your most recent items newest first. Opening the flyout marks those items as seen, so the bell clears its count once you have looked, whether or not you read each one.

The flyout is built for a glance. Each row shows a title, a short body when there is one, and how long ago it arrived, with a small dot on anything still unread. A switch labelled Unread narrows the list to just those, and Mark all as read clears them in one action. Click a row and, if it points at a record, you land on that record with the notification marked read on the way. When you want the full picture rather than the recent slice, View all notifications at the foot of the flyout takes you to the inbox.

The inbox at Settings → Notifications is the same notifications without the time pressure of the flyout. It opens under the header Notifications with the subtitle All your notifications, a search box, and filters that narrow the list by status (New, Unread, Read, Archived) and by type. The type filter names the exact kind of each notification, Plan Updated, Task Completed, Member Joined, Estimate Drift, Test, so you can pull up one sort of thing at a time. You can sort newest or oldest first, mark a single item read from its row or clear everything with Mark all as read, and load older items as you go. A Settings button in the header takes you to your preferences. Clicking a row opens the exact record it is about, the specific plan or initiative, sometimes a particular section of it, with the notification marked read on the way.

Both surfaces update live. A new notification slides into the flyout and the count on the bell ticks up the moment the change happens, with no refresh, and reading one in any place, the bell, the inbox, even the link in an email, clears it everywhere at once. You do not have to reload to see what just arrived or to keep two open tabs in step.

Behind those surfaces is a small lifecycle. A notification is created unseen. Opening the bell moves your unseen items to unread, which is what clears the count without pretending you have read anything. Reading one, by clicking it or marking it read, moves it to read. Archiving sets it aside as archived. The states are why the bell count and the unread dots can disagree: the count tracks what you have not looked at, the dots track what you have not read.

Who gets notified

A notification is never broadcast to the whole workspace. For any change, the platform works out a precise set of recipients and tells only them. As a rule, that set is the people watching the thing that changed, plus its owner.

Watchers and the owner

You become a watcher the natural way, by being involved. Create an initiative and you watch it. Edit a plan and you start watching it. Get assigned one and you watch it from then on, all without keeping a list, because participation adds you. The owner of a record is always in the set on top of the watchers, so the person accountable for a plan hears about it even on a change they were not part of. The two together, watchers and owner, deduplicated, are who a notification reaches.

Watching by hand

When the automatic watching is not enough, you can set it by hand. Every initiative and plan carries a Watch toggle in its header: click it to follow a piece of work you have not touched, click it again to stop following one that has gone noisy. The button reads Watch when you are not following and Watching when you are, so the state is never a guess. Watching by hand is the one lever that lets you track work you are not otherwise tied to, or step back from work you are.

The exceptions, and the one name always missing

A few notifications reach a little past the watchers-and-owner rule, by design. Being set as the owner of a project or a goal notifies you through the Assignments category, even though watching itself tracks initiatives and plans. An estimate drift proposal reaches the item's owner, whoever it is assigned to, its watchers, and the lead of the sprint team, so the people who carry the estimate all see it. And a documentation health proposal, the kind raised when a review finds stale docs, goes to the workspace's administrators, because acting on it is their call. The shape is the same in every case: the platform tells the specific people the change is for, and no one else.

One name is always missing from that set: yours, on your own actions. The platform never notifies you about something you just did. If you move a plan to blocked, the plan's other watchers hear about it and you do not, because you were the one who did it and already know. This is the first half of the platform's quiet by design, and the agent half is below.

The categories you can tune

Notifications are grouped into categories, and your preferences are set per category rather than per event, so you decide in broad strokes what is worth interrupting you. The preference editor gives you five to tune:

• Activity covers creation and updates on the initiatives and plans you watch or own: a new initiative, an initiative edited, a plan created under one, a plan updated.
• Status Changes is the subset worth pulling out on its own: when an initiative or plan you watch or own moves status, to blocked, approved, in progress, done.
• Assignments is when someone sets you as the owner of an initiative, plan, project, or goal. This is the one most people leave on everywhere.
• Estimate Health is when a spec change re-proposes an AI estimate on a plan or bug you own, are assigned, watch, or lead, the proactive half of estimate health reaching you when no one is looking at the item.
• Membership is when people are invited to or join your workspace.

Task notifications sit alongside these, with one difference: they are always on rather than a card you tune. When an agent task you set running finishes or fails, its owner gets told in the inbox, with the failure carrying the reason it stopped. There is no toggle to switch them off because a task you started is a thing you asked to hear the end of; they just arrive, in the Tasks category, like the rest.

If a single change would match more than one category for you, you get one notification, not a pile. The most specific category wins: an assignment beats a status change beats a general activity update. So reassigning a plan that also touches its status does not arrive three times.

Where notifications reach you

A category can reach you on up to three channels, and you choose which per category.

• In-app is always on. It is the bell and the inbox, delivered the instant the change happens, and it is the channel every workspace has without setting anything up.
• Email sends the notification as a message to your address. It carries a View in App button that opens the exact record, and a Mark as read link that clears the notification from your inbox the moment you click it, so handling something in your mail keeps the in-app inbox honest without a second trip.
• Microsoft Teams posts the notification as a rich card into a channel through a Teams workflow webhook, with the same deep link back to the record. Teams is a shared channel rather than a personal inbox, so when one change is relevant to several people who all have Teams on, the platform posts it once instead of once per recipient, and the channel stays readable.

Email and Microsoft Teams are part of a plan's entitlements, and the per-category channel switches appear once your plan includes one of them, so a category card on the default plan shows just its on-or-off switch and gains the channel choices when email or Teams is added. A channel in your plan that still needs setup, a Teams workflow webhook that has not been pasted in yet, reads (Not configured) until it is ready, and the toggle for a channel your plan does not include reads (Not licensed) so you can see the channel is there and how moving up a plan turns it on. In-app needs neither, which is why it is the channel you can always count on.

Send yourself a test

Once you have turned on a channel, or pasted in a Teams webhook, you want to know it works without waiting for something real to happen. The preferences page has a Send Test button in its header for exactly that. Click it and the platform fires a test notification to you across the channels you have on, then tells you how each one went, a line that reads something like in-app: sent, email: skipped (not enabled). A failed line points straight at the channel to fix.

It is a self-service check, not an administrator-only one: anyone can send themselves a test to confirm their own setup. It is the fastest way to answer "did my email actually turn on" or "is that Teams webhook live," and it is the first thing to reach for right after configuring a channel.

Marcus Reed pastes the Teams workflow webhook into Organization Defaults, saves, and clicks Send Test. A card lands in the team's channel a second later, the status line reports Teams as sent, and he knows the channel is live before a single real notification depends on it.

Three layers of preference

What you actually receive is resolved from three layers, applied in order, and the order is what lets a workspace set sane defaults while leaving individuals room to adjust.

The first layer is the system default: every category on for in-app, email and Teams off until someone turns them on. The second is the workspace default, set by an administrator on the same preferences page under Organization Defaults, applied to everyone. The third is your preference, which adjusts the result for you alone.

The one exception to "the most specific wins" is the workspace's power to switch a category off for the whole workspace. When an administrator disables a category in Organization Defaults, that is authoritative: a member cannot re-enable it for themselves. The page says so in as many words, Disabling a category here prevents members from re-enabling it. It is a deliberate kill-switch, for a category an organization has decided no one should be paged about, and it sits above personal preference rather than beside it. Turning a category on at the workspace level still leaves each person free to turn it off; turning it off is final.

Marcus Reed gets a complaint that Estimate Health is paging half the team through a noisy migration sprint. He opens Organization Defaults, switches Estimate Health off, and saves. From the next change on, no one is notified for it, and no one can quietly switch it back on for themselves. When the sprint settles he turns it back on at the workspace level, and each person's own preference for the category takes over again.

Quiet by design

A platform where agents act all day could drown you in its own activity. Disco Parrot is built not to, and the restraint is deliberate.

You already saw the first half: you are never notified about your own actions. The second half is about the agent. When an agent edits an initiative or a plan, the routine activity and status notifications for those edits skip it, so an agent grinding through a long piece of work does not page every watcher on every save. What still reaches you is the part that needs a person: when an agent assigns you as owner, you hear about it, because that is a handoff to you and not just churn; and when a task you started finishes or fails, you hear about that, because you asked for it. The line is between an agent's incidental edits, which stay quiet, and the moments an agent's work lands on your desk, which do not.

Tom Asare sets an agent to rework a plan's acceptance criteria and steps away. He comes back to one notification, not forty: the agent's dozens of edits stayed quiet, and the single line in his inbox is the task itself, finished and ready for him to review. The churn never reached him; the result did.

The result is an inbox you can trust to mean something. A notification in Disco Parrot is a thing a person watching or owning the work would want to know, not a log of everything that moved.

How long notifications stay

Notifications you have read or archived are kept for 90 days and then cleared, so your inbox does not grow without bound and old, handled items do not pile up behind the new ones. Retention applies only once you have dealt with an item, which is the safe direction for it to apply.

Who can change what

Everyone manages their own inbox and their own preferences; setting the defaults for the whole workspace is an administrator's job.

Reading your own notifications and tuning your own preferences are self-service, on scopes every member holds, because your inbox is yours. Setting the Organization Defaults, the workspace-wide switches and the authoritative kill-switch, takes notifications.tenant-prefs.manage, which sits with the administrators who own roles and permissions for the workspace. Configuring the Teams webhook lives in the same administrator section, since it delivers for everyone.

Why notifications work this way

The shape of this system follows from one decision: a notification should mean something. Everything else is in service of that. Recipients are watchers and owners rather than the whole workspace, so you hear about your work and not everyone's. Your own actions and an agent's incidental edits stay quiet, so the inbox is signal rather than a feed. Categories and channels are yours to tune, so the threshold for interrupting you is one you set. And the workspace can switch a noisy category off for everyone, with that switch winning over personal preference, so an organization can make a decision once and have it hold.

The three-layer resolution is the quiet engine behind it. A sensible default out of the box, a workspace default an administrator can shape, and a personal adjustment on top, applied in that order, gives a new member something reasonable on day one, gives the organization a lever, and gives the individual the last word on everything except the categories the organization has reserved. It is the same pattern that runs through the rest of the platform: a shared default you can lean on, a personal override where it is yours to make, and a clear rule for which wins.

For a teammate, notifications are how you stay on top of the work you care about without watching it. Leave Assignments on, tune the rest to taste, and the bell tells you when something you own or watch needs you.

For a team lead, the channels are how the important changes reach your team where they already are. Turn on email or Teams for the categories that matter, and a status moving to blocked reaches the people who can unblock it.

For an administrator, Organization Defaults is one place to set the workspace's baseline and switch off a category nobody should be paged about, with the kill-switch holding against personal preference. You set the defaults and the Teams webhook; everyone tunes their own from there.

For the person who owns trust, the quiet by design is the answer to "does an agent acting on our behalf become noise." It does not: an agent's incidental edits stay silent, its handoffs and the tasks people start do not, and nothing about a notification reveals more than the watcher or owner was already entitled to see.