Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

What are your best practices for reading and responding to Jira notifications?

Marcus Bittman
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 26, 2026

Hi Atlassian community,

I recently have been working with teams where written communication is super important and Jira notifications are the only way to keep up with the number of changes.  I often receive 20-40 notifications a day that I need to read/respond to.

My workflow is to use https://home.atlassian.com/notifications as the main portal for reading notifications.  My issues are:

1. When marking notifications as read, they often re-appear within the next few minutes so I sometimes have to mark them as read multiple times.

2. To read a message, you have to open another tab, which is infuriating b/c it's a shift in context.  I really wish Jira would have made this view work like Filter -> Detail view where you have a ticket list on the left and you click on a ticket and it shows up on the right.

3. I've played with the shortcut keys some, but the expand ("e") key doesn't do anything the majority of the time.

I feel like there has to be a better way and am hoping that someone has found it :-)

One thing I tried is Chrome's split view -- right click and "Open Link in Split View" or "Open Link in Right Side"

1 answer

0 votes
Peter Kerrigan
Contributor
August 26, 2026

I’ve been experimenting with an angle on this; still early, not something I’ve rolled out in a production sense yet, so take it as a “here’s a direction that looks promising” rather than a proven setup.

One heads-up first: the tool I’m using (Dia) is macOS-only today, with a Windows version coming this fall (https://www.diabrowser.com/windows). So for now this approach assumes you’re on a Mac. I chose Dia since it's owned by Atlassian and easily connects to their Cloud products, but other providers may be able to reproduce the solution I'm experimenting with.

The idea: instead of trying to make the Atlassian Home notifications page behave, connect Dia to Jira Cloud as a triage layer in front of the notification firehose.

While this doesn’t fix the specific bugs you mentioned (reappearing read-state and the flaky “e” shortcut, those are on Atlassian to solve), it does look like it can take a lot of the pain out of the sheer volume. A few things I’ve been testing with Dia:

Scope to what actually involves you. Structured filters come straight from Jira’s own fields, so you can pull only the tickets where you’re the assignee, a watcher, or the reporter. For @mentions and comment activity, you don’t even need a query, Dia reads the notification feed itself (the same firehose that’s piling up) and classifies each item: a comment that needs a reply, an FYI, or noise. Between the two, 20-40 items collapse down to the handful that actually need you.

Read and reply in one place. This helps alleviate the context-switch of opening a new tab per notification. Dia can generate a single list-and-detail view (ticket list on the left, full detail + comments on the right), read updates inline, and post a reply from that same view instead of tab-hopping.

Make it one keystroke. Dia lets you save your own “Skills” which can be called with reusable slash commands. The plan I’m testing is a “/tickettriage” command that rebuilds that scoped board against live Jira data whenever you call the command, so it’s always current rather than a stale saved page.

Let the morning pass be automatic. Dia’s “Morning Brief” is an automated weekday summary that folds in relevant Jira activity (plus Slack/email/calendar) if you have Atlassian connected. The theory is: skim that with your morning coffee, then use /tickettriage for deeper checks during the day. Or if you like /tickettriage then just use that beginning-to-end of your day.

The intended net effect is that the notifications page stops being the thing you live in; you’d be working from a filtered, readable list instead, so the read-state quirks matter less. It also lets you display all filtered tickets in the manner you’re requesting: tickets in a list on the left hand side with ticket details, fields, and the ability to comment listed on the right.

I haven’t lived on it long enough to swear by it, but the building blocks are there and it feels like a reasonable path. Happy to report back once I’ve run it for real.

Prototype, improvements still needed:

Screenshot 2026-08-26 at 4.16.13 PM.png

You may also be thinking, "What about Rovo?" Worth calling out, since it can do a lot of this natively. The new Jira Delivery Agent handles health checks, standup digests, stakeholder updates, and even stale-work follow-ups, and agents can run on a schedule via automation, so a recurring digest posts itself with no browser involved. If your goal is team-level coordination inside Atlassian, that’s probably the more elegant, lower-maintenance route and I’d start there. The difference is the display: Rovo renders inside Atlassian’s own surfaces (chat, automation output, the List view) rather than a custom list-and-detail board you control, and it’s oriented toward team/space coordination more than a personal, cross-tool reading surface. So I think of them as complementary: let a Rovo agent run the automated team digest, and use the Dia board as the personal triage-and-reply view during the day.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events