Notification preferences and alert management.
OneOrg lets each user control which updates reach them and through which channels, while admins configure the underlying provider and basic policies.
Set preferences that match your work style
Use the notification preferences in account settings to decide:
- Which types of events you want to be notified about.
- Whether you prefer in-app alerts, email, or both.
Practical setup:
- Turn on notifications for:
- Direct mentions, - High-priority task changes, - Project activity where your role is critical.
- Turn off or mute:
- Low-signal activity in projects where you are an observer, - Events you already track via dashboards or automations.
If everything is turned on, you will lose the ability to notice what actually matters. A clean setup reduces noise without cutting important updates.
Align with project and team norms
Notifications are personal, but project communication is not.
Use these rules:
- If your role requires fast response (incident handling, support triage), enable relevant alerts.
- If you are mainly reviewing or observing, prefer project views over real-time alerts.
- If the same event is covered by an automation or webhook, you may be able to reduce personal notifications safely.
If the team complains about missed messages:
- First confirm their notification preferences are correct.
- Then adjust project structure, channels, or automations so the right signals are clear.
When to use alerts
Use alerts when:
- A delay in response would impact the project or client.
- A task, decision, or handoff depends on your input.
- You are coordinating across many projects and need early warnings.
Avoid using alerts when:
- You are not responsible for timely action.
- You already track the same updates via dashboards, automations, or regular reviews.
A good rule: if you are not the intended responder, you probably do not need a real-time alert for that event.
Use notifications as a focused signal, not a broadcast system. Align them with your role and responsibilities: if you are responsible for a project or incident, enable alerts; if you are observing, use project views instead. Avoid turning everything on “just in case” because that destroys the ability to notice what truly requires action. If the team complains about missed updates, adjust roles, automations, and channels so that the right signals reach the right people.
Use notification preferences as a team norm, not just a personal setting. Encourage people to align their alerts with their actual responsibilities: if you are responsible for a project or incident, enable those alerts; if not, rely on project views instead. If the team relies on certain alerts for critical work, document that expectation so new members configure their preferences correctly on day one. A team that shares this discipline reduces missed messages without increasing noise.
If you are setting up a new organization or onboarding a team, include notification preferences as part of the onboarding checklist. Define which alerts each role should enable by default, so people start with a clean configuration instead of guessing. Review those defaults quarterly: as workflows mature, the right signals change. That keeps the notification system from becoming a quiet source of burnout.