Notifications
Notifications in LadVen OS help you notice assignments, comments, due date changes, mentions, rework returns, automation actions, and other events that require attention.
A notification does not replace work inside the task card. It only shows that something changed in the work context. A decision, question, result confirmation, or reason for a change should stay in the task, comment, file, checklist, or related object.
Where to find them
Notifications are gathered in the bell in the portal's top bar. It opens recent notifications: each card identifies its source — tasks, CRM, chats, or system-wide — while events about the same object are combined into one card. From any notification you jump to the related object instead of resolving the event in the list itself.
- Notification bell — an unread counter and a panel of recent events, updated in real time while the portal tab is active;
- Jump to the object — a notification opens the task, comment, deal, email or document it concerns;
- Activity feed — for a broader stream of activity, use the Feed section, not the bell.
Grouping and read state
The bell groups events for the same object, so one object can have several reasons and changes while appearing as one card. Opening the card marks that object's events as read; Read all walks through unread pages, while Show more loads the next cursor page. If access to the object has been revoked, you can still read the notification but the jump is blocked — that is not a bell failure.
Notification types
Notifications arrive on events from different modules. The main groups:
- Tasks — assignment, task changes, checklist edits, a new comment and reaction, an approaching or reached deadline, a reminder;
- Time tracking — a time-entry conflict that needs review when the current backend/configuration exposes that domain and event; a dedicated toggle may be absent;
- Chats and calls — a new message, a mention, an incoming and a missed call;
- CRM — deal assignment (with a pop-up notification of who assigned it and an "Assigned to you" marker on the deals board), a new message and mention, a comment, a stage change and a deal field change, plus updates to a followed deal;
- Mail — a new email in a connected mailbox;
- Documents and signatures — document updates, inbound documents and inbound exchange candidates, signature requests, sending and viewing, partial or completed signing, cancellation, decline, expiry and signature failures.
An event has a priority (normal or elevated) — it helps separate what needs attention now from the background stream.
Delivery channels
The same event can arrive in several ways. Tune the channels so important things are not missed and the background does not distract:
- In the app — the bell, unread counter, and toast cards; new events arrive in real time while the portal tab is active;
- On the desktop — a system notification only in the LadVen OS desktop (Tauri) runtime, usually when the tab is inactive. High-priority alerts and incoming or missed calls may still request attention while the window is focused;
- Push in the browser or app — for events you cannot miss outside the portal. The browser permission and the push capability must both be available;
- Email — an optional channel available only when the organisation's system email profile is configured, enabled, and able to deliver. If the profile or transport is unavailable, the switch is disabled with a reason;
- Sound and tab title — separate settings: turn sound off while keeping the unread counter in the tab title.
If a channel is not needed or is noisy, turn it off in the notification settings rather than ignoring the whole stream.
In your profile you can enable or disable channels, Do Not Disturb, and individual event types within the domains available to your scope (tasks, CRM, chats, mail, and documents). Only domains available to your current scope are shown; unavailable domains do not appear. When Do Not Disturb is on, sound, toast, and desktop alerts are suppressed; only high-priority events pass if the corresponding option is enabled. The bell and unread events remain available.
Notification scope follows the account type. Staff users see the domains allowed by the workspace policy. An Extranet user must not receive internal domains by default: the usual external scope contains chats, documents, and extranet events, while tasks, CRM, and mail stay hidden. When a channel or domain is unavailable, use the reason shown by the portal instead of trying to enable it through a workaround.
When to react
Open the notification right away when it is connected to:
- a task where you own the result;
- a mention in a comment;
- a deal or inquiry assigned to you;
- a due date, status, assignee, or priority change;
- work returned for rework;
- a request to accept a result or check a file;
- an automation action that changed a task, participant, or due date.
If the notification only informs you about an event, first decide whether action is needed. Not every notification needs a reply, but important notifications should lead to a clear next step.
How to read a notification
- Open the notification and go to the related object.
- Check the latest comment, status, due date, and assignee.
- If action is needed, leave the answer in the work context, not in a private chat.
- If the notification is about a file, check that it opens and that the current version is clear.
- If the event was created by automation, check the result: status, participants, due date, comment, or related task.
- Task notifications clear after you actually view the task in an active tab — from the bell, list, kanban, or direct link. Opening it in the background or in a new inactive tab does not confirm reading until you focus that tab; if the mark-read request fails, retry after focus.
Do not clear notifications mechanically. For a manager, this risks missing acceptance, a blocker, an overdue task, or a responsibility change. For an employee, it risks missing a question that blocks execution.
What to Leave in Notifications
After checking a notification, decide where the work trace should stay:
- a short reaction or confirmation can be sent from the notification if the context is obvious;
- a decision, due date change reason, rework request, or result acceptance should be written in the source card;
- a file should be checked in the card or document where the version and owner are visible;
- a disputed question should move to a task, CRM, or document comment so every participant sees it;
- after the automatic clear, still check the next step in the source card: a read state does not replace the action.
This keeps notifications as an attention inbox, not as a separate place for decisions.
How to reduce noise
When there are too many notifications, the problem is often not the feed itself but roles and process rules.
Check whether:
- observers were added "for visibility";
- all participants are mentioned without a reason;
- automation rules create extra comments and notifications;
- events are duplicated in private chats and tasks;
- you are subscribed to processes where you do not make decisions;
- whether extra delivery channels (desktop, push) are on for background events.
A good notification flow shows not everything that happened, but where a person needs to pay attention. In LadVen OS this is especially important for tasks: extra noise reduces reaction to real blockers, acceptance, and due date changes.
Related Scenarios