You can now treat Pomavo as a personal command center for ticket activity. Inbox and Notifications brings follows, unread triage, replies, reactions, and set-based search together so you can see what changed and act faster.
Follow tickets to build your notification graph
The follow system is the foundation of this release. When you follow a ticket, Pomavo knows you want to hear about meaningful activity on that ticket even if you are not currently assigned to it.
Following is useful for support escalations, cross-team bugs, project planning tickets, and any issue where you need awareness without owning every next step. It also gives Pomavo a clean signal for which ticket events should appear in Inbox.
| Follow behavior | What you get |
|---|---|
| Explicit follow | You subscribe to ticket activity you choose |
| Created ticket | You stay informed about work you started |
| Assigned ticket | You receive activity for work that now involves you |
| Commented ticket | You keep context after joining the discussion |
| Unfollowed ticket | You stop receiving followed-ticket activity |
Followed tickets also become more useful in Search, because follow state is indexed with ticket activity. That means the same tickets you care about in the Inbox can be queried, filtered, and saved as repeatable views.
Following is not a replacement for assignment. Assignment says you own work, while following says you want activity. You can use both together.
Inbox gives every user a notification center
The Inbox is a personal notification center for ticket activity. It aggregates events that relate to you across tickets you follow, tickets you authored, tickets assigned to you, tickets where you were mentioned, and comment threads you own.
Instead of checking projects one by one, you can open Inbox and review the work that needs your attention. The sidebar badge shows your unread count, so you can see whether anything changed since your last pass.
| Notification source | Example |
|---|---|
| Mention | Someone references you in a ticket field or comment |
| Assignment | You are added to a user field such as assignee or reviewer |
| Status change | A followed ticket moves to a different workflow state |
| Field change | A followed ticket has a field value updated |
| Comment | A followed ticket receives a new, edited, or deleted comment |
| Reply | Someone replies to a comment you authored |
| Reaction | Someone reacts to a comment you authored |
| Link | A followed ticket gains or loses a linked ticket |
| Attachment | A followed ticket receives a new file |
The result is a workflow that scales from quiet personal backlogs to busy shared projects. You can keep an eye on the signals that matter without turning every project page into a daily checklist.
Unread-only filtering focuses triage
Unread state is now a first-class part of notification triage. You can narrow the Inbox to unread items only, clear individual items as you review them, or return to the full list when you want historical context.
Unread-only mode is especially useful when a project is active and the Inbox includes both recent changes and older context. It keeps your first pass short, because you only see items you have not processed yet.
| Triage action | When to use it |
|---|---|
| View all | You want full notification history |
| View unread only | You want the shortest actionable list |
| Mark one item read | You handled a specific notification |
| Mark all read | You completed a triage sweep |
| Follow or unfollow | You want to tune future notification volume |
The unread model is intentionally personal. Reading a notification does not hide it from teammates, and their read state does not change yours.
Mark all read keeps noisy days manageable
When you return after a busy release, an incident, or a long planning thread, individual cleanup can be too slow. Mark all read lets you clear the current unread backlog once you have reviewed what you need.
This action pairs well with the unread-only filter. You can open unread-only mode, scan the high-signal items, open any ticket that needs action, and then clear the rest when the triage pass is complete.
Open the Inbox from the sidebar and check the unread count.
Switch to unread-only mode to hide notifications you already processed.
Open tickets that need action, such as replies, reactions, or assignment changes.
Use mark all read when the remaining items no longer need individual handling.
Because the Inbox remains tied to ticket history, marking notifications read does not delete ticket activity. It only updates your personal notification state.
Replies now support threaded discussion
Comment discussions are easier to follow with threaded nested replies. A reply belongs to a specific parent comment, so follow-up questions, clarifications, and decisions stay near the comment that started the conversation.
Threading helps when a ticket includes several topics at once. A bug report might include reproduction steps, customer impact, release timing, and ownership. With nested replies, each thread can resolve separately instead of forcing everyone into one flat stream.
| Discussion pattern | Why threading helps |
|---|---|
| Clarifying a requirement | The answer stays beside the original question |
| Reviewing a fix | Feedback stays attached to the review comment |
| Confirming a decision | The confirmation is visible in context |
| Escalating a detail | The nested thread shows what triggered the escalation |
Replies also generate notifications for the comment owner. If someone responds directly to something you wrote, you get a notification even if the larger ticket is busy.
Reactions acknowledge comments without extra noise
Comment reactions add a lightweight way to respond. You can acknowledge a comment, agree with an update, or signal that a note was helpful without adding another full comment to the ticket.
Reactions are not just visual feedback. When someone reacts to a comment you authored, Pomavo can notify you through the Inbox. That keeps acknowledgements visible without requiring everyone to write a separate response.
| Reaction use case | Benefit |
|---|---|
| Confirming you saw an update | Avoids short acknowledgement comments |
| Agreeing with a proposal | Shows consensus without interrupting the thread |
| Marking a useful detail | Helps readers find important comments |
| Responding to your own comment activity | Gives authors feedback through notifications |
Use a reply when you need to add information, ask a question, or make a decision traceable in the thread.
Pinned projects keep high-priority work close
Pinned projects make navigation faster for the work you visit often. If you support a critical queue, manage a release board, or monitor an operations project, pinning keeps that project close in the sidebar.
This is a small interaction with a large workflow impact. You can combine pinned projects with Search, saved queries, and the Inbox to move between project context and personal notifications quickly.
| You pin a project when | You benefit because |
|---|---|
| It is part of your daily workflow | It stays easy to reach |
| It is temporarily high priority | You avoid hunting through project lists |
| You own triage for it | You can jump from Inbox to project context |
| It hosts a launch or incident | You keep the active workspace visible |
Pinned projects do not change permissions or visibility. They only change how quickly you can reach projects you already have access to.
Search supports IN and NOT IN for cleaner saved views
The Search DSL now supports set membership with in and not in. This is ideal for workflow states, priority buckets, team lists, and any field where you want to match several values without writing a long chain of or clauses.
status in ("To Do", "In Progress", "In Review") and assignee = @me
order by created_at desc(template = "Bug" or template = "Incident") and status not in ("Done", "Closed")
order by priority desc| Operator | Use it for |
|---|---|
in | Include any value from a known set |
not in | Exclude completed, archived, or irrelevant values |
@me with in | Build personal saved queries that follow the current user |
order by | Keep the resulting list useful after filtering |
Set membership makes saved queries easier to read and maintain. A team can express active work as one status set and reuse it across support, engineering, and planning views.
Notification indexing connects activity and search
Ticket follows are now part of the indexed activity model, which makes notification-driven workflows line up with search-driven workflows. You can be notified from the Inbox, then use search to slice the same work by status, assignee, template, project, or date.
This matters when personal attention and team reporting meet. A support lead can follow escalations, process their Inbox, and still build a saved query for active escalations that uses the same ticket data.
| Capability | Where you use it |
|---|---|
| Follow signal | Inbox delivery and ticket subscription |
| Unread state | Personal Inbox triage |
| Search fields | Saved queries and reporting |
| Set operators | Compact filters over workflow states and values |
The result is a more consistent Pomavo: notifications tell you what changed, search tells you what matches, and both point back to the same tickets.
Next up, notification preferences and delivery channels can build on the same follow and unread foundation, giving you more control without changing how ticket activity is captured.