Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Is there a way to notify if/when another agent is in a ticket?

I have a very small team of myself and one other help desk agent.

We both answer tickets on an "as available" basis, and there are times when we're both sitting down working at the same time.

Is there a way to add some sort of a notice or a flag if/when somebody is already looking at a ticket so we can avoid the both of us responding to the same ticket at the same time?

Any information on this would be greatly appreciated.  Thanks!

3 answers

HI @Drew Angell ,

Both suggestions by @Nic Brough -Adaptavist- and @Dam are perfectly feasible approaches, from a technical perspective. Either by assigning a ticket or by changing a status or even a combination of both: the tools give you options to indicate that someone is working on it. I believe that's what you asked for 🤗.

In the end it all boils down to communication. If you are only 2 people and manage a limited number of tickets, make an agreement between you two on how you are going to avoid working on the same ticket. It seems that just talking might help, but making it visible in the tool is quite practical too, especially if your team were to grow in the future.

Updating the status of a ticket or setting the assignee has the additional benefit that both can be used as a trigger to track SLA's or over time monitor how you're doing.

On a last note: updating the assignee on a ticket just indicates "who is currently responsible" for it. Nothing stops you from clearing that or handing it over to your colleague when you're no longer on call. It just creates clarity in a very easy to track fashion.

Hope this helps!

Thanks for the feedback.  I'll just have to open my mind a bit and make one of these options work.  :)

1 vote
Dam Community Leader Jun 26, 2022

Hi @Drew Angell 

Is there a way to add some sort of a notice or a flag if/when somebody is already looking at a ticket so we can avoid the both of us responding to the same ticket at the same time?

Simply add a status in your workflow to show that someone is working on it... Something like "Taking into account" status or "Investigating" status so that other people will know that someone is working on it. 

Then with a dedicated status you can build a dedicated queue in JSM and also statistics around this status like "Time in status". You will have a lot of benefits with a dedicated status. 

It's a simple solution but you know sometimes, "the simpler, the better". 

I hope it helps. 


Thanks.  This sounds like I could work with it if I can use Automation.  I don't see anything under Automation like "When an issue is being edited" or "being viewed"..??  

Do you know of an Automation trigger I can use to set the status to "Investigating" when somebody is viewing it in their browser?

1 vote

The obvious way to do it is to use "assign to me" as soon as you choose to say "hey, I'll get this one". 

A lot of people (especially in larger teams of agents) will then also set permissions such that the assignee is the only person who can make most/all changes to it (even just "only the assignee can reassign"), so once you've grabbed one, the rest of your team get met with a "nope, you can't change this now, it's someone else's now" message if they try to update it.

I appreciate the feedback, but that flow doesn't work well for me. 

It's just me and one other person, and we really don't have a whole lot of tickets.  The tickets we have usually aren't all that unique, either.  Same sort of stuff that both of us can easily pick up where the other left off.

When I'm here ready to go I don't want to ignore customers just because their ticket isn't assigned to me, and I don't want my team member ignorning them just because they're assigned to me.  

We can both help, so when we're here, I want to help.  Our customers like this a lot better, too, because they get answers more quickly.

So, is there a way to do what I'm asking?  It's a pretty standard feature in most other systems like this.

Jira doesn't actually care if someone looks at an issue (and it can be hard to define "looking" - open directly in the issue view, sure, but what if the issue appears in a search in the issue navigator, or on a board, or in a roadmap?  All places where someone could be "using" it and jump off to change it)

Basically, you'll need to amend an issue when one of you is saying "I'll get this one".  Assignee is a good choice for a lot of cases, but it's not the only option, and it can be automated (as can other options).  An obvious one is when an issue is picked up by an agent, they'll move it from "to do" to "in progress".  You could automatically set the assignee to "current user" when someone does that.  Assignee also has the advantage of making reporting easy.  "Show me the open stuff I've got assigned" is a doddle, but doesn't stop you looking at just "show me all the open stuff"

Thanks, this is helpful, but can you point me to which Automation trigger would allow me to adjust the status when the issue ticket is viewed?  I'm not seeing how I would automate the switch from Open to In Progress, for example..??

There isn't one.  There's many different ways to view a Jira issue, and you wouldn't want to trigger change when people view an issue.

It's the other way around - you should be automating "set assignee" or some other "person has got this" flag when an issue is moved from open to in-progress.

Hmmm, I guess that puts me in the same place then.  If I have to manually set the status of the ticket I might as well manually assign it to myself.

But then once it's assigned to me, my other guy will assume he shouldn't ever touch it, which isn't ideal.  So then I'd have to set it back to Unassigned when it goes to "Waiting for Customer" status.

Which...maybe that's my answer.  Right now I have it auto-assign new tickets to the primary user in Service Desk.  If I remove that so they come in Unassigned, then we'd have to remember to assign ourselves each time we open a ticket.

That's the part that seems so strange to me there isn't some trigger that says "I'm editing this issue."  That's different from simply viewing it on a roadmap or search results, etc.  I'm talking about actually clicking into the ticket so I can edit values.  

Consider something as simple as WordPress with Pages and Posts.  If I'm editing a Page or Post and another user attempts to edit that same piece of content, it gives them a notice that "User A is currently editing this content.  Would you like to cancel or boot them out of it?"  

It doesn't matter where I edit from.  It still works fine.  Shocking to me something similar doesn't exist in Jira.  

Jira is not a documentation tool, it's an issue tracker, there's no reason to tell people that someone else is looking at, or has it open in "edit" mode (especially as there's loads of different ways to "edit" an issue).  If you're editing an issue, that's fine, you save your changes.  The fact someone else might be looking at it is irrelevant. 

If they make changes to it after yours, their edits will be recorded as being after yours.  If your change was one that changes the access, their edit could be blocked - this is the main reason we tend to use "assignee" for indicating that someone is responsible for an issue.  If you change the permissions so that "Edit issue = assignee" (and only that), then this solves the problem, it'll block the second update after you've assigned yourself to it.

I am not sure what the problem is here, I can't see why it's a problem to make the changes to the issue when you assign them.   You say "If I remove that so they come in Unassigned, then we'd have to remember to assign ourselves each time we open a ticket." - no, that's the whole point of the automations I mentioned - you could automate setting the assignee to the person making the change, so you don't have to think about it.

Thanks for sticking with me here.  I swear I'm not trying to be difficult.

The problem occurs when we both happen to be looking at the same ticket at the same time, typing up a reply.  By the time I'm done and I submit my comment, it refreshes, and only then do I see that my other guy just finished his reply and submitted it a few seconds/minutes before me (or vice-verse.)

Now we've both spent our time on the same ticket, and the customer gets confused with the same (or slightly different) reply from two people at the same time.

To avoid that, I want to be notified some way if I'm entering a ticket that he's already in and has already started typing a reply to, but hasn't yet submitted the comment.

The way I'm understanding the options you're suggesting, it wouldn't help this particular problem because the Automation wouldn't trigger until after he submits his comment.  That's too late.  I need to before hand that he's in there working on that particular ticket.

What am I overlooking here?

I think the problem here is that you don't have a process that makes it clear who is working on something, which you can't fix in software.

Well, that's exactly my point.  I'm trying to make it clear who's working on something by automatically assigning them when they start working on it.

This can indeed be fixed in software, just like WordPress, SalesForce, and many other CRM/Project Management systems I've used.

So how exactly are you saying I should handle this?  Just assign tickets to somebody randomly, and only that person can ever work on that ticket?  Meaning if somebody else able and willing to answer the question is available, they should just ignore it?

I see the problem, it's a natural way to work when you're a small close-knit team, especially if you're co-located

Growth forces more rigour - I tell stories about Adaptavist's growing pains - when I started, I was the 27th-ish employee and when I picked up a piece of work, I could mutter "I'll get ABC-123" so the people in the single room we were all working in knew not to pick it up, but as we've grown, that doesn't work any more, I can't shout across thousands of miles to tell everyone I've picked something up, and we can't rely on slack or anything else like that because you don't know who might be reading it when they need to.  

So, the simple fix is to move the "tell Jira you've started working on it" to before you actually do anything with it.

I've used the assignee for it because that's been the most useful way to do it in the cases I've run into, but you could do it in other ways.  The important bit is that you put something on the issue that says "I've got this one" before you do any work on it, even just the throwing it back to the customer for questions, or a quick comment.

Some of the options are variants of

  • Assign the issue to me before commenting/editing
  • Move issue from to-do into in-progress before doing any work on it
  • Set a custom field to say "leave this alone, someone else has it" before doing any work n it
  • Do the initial comment and have that set a flag for "current user has this one" and  maybe move it through the workflow 

All of these rely on telling Jira that someone is actively working on something as they start the work.  Just having someone looking at an issue or typing things into it is not good enough - there's times when a comment is literally a comment, and does not mean "I've got this"

Thanks again for all the feedback.  I'm still having a hard time accepting this.  Not because I think you're wrong or anything like that, but just because I find it odd that something I see in so many other solutions is being treated like such an impossibility here.  

Each of those options you have laid out requires a manual action, correct?  I realize it could be literally one click (assign to myself), but that's just one more click on top of all the other clicks, and one more thing I have to document in procedures/systems, etc.

Given this limitation I can come up with something that will work for us, but it just leaves me feeling like I'm creating work-arounds instead of what I actually want to do.

Again, thanks for all the feedback.  I'll figure something out.

The fact that Jira lacks a bunch of modern features, like being able to see which agents are viewing a ticket or who is typing a comment or refreshing pages/data in realtime when having a ticket open is of course a problem and the solution unfortunately cannot always be "this is the way you're supposed to work to make Jira work".

When my team receives a ticket we all also receive an email. Imagine the scenario where three of us clicks the link in that email and open up the ticket. I assign myself to the ticket but no one sees that because the ticket isn't refreshed. Then the second guy assignes himself but I'm not aware of that. Then all three of us starts commenting, asking the user for more information. Should we all have to call each other or have a chat open to coordinate this? The suggestion to make the ticket only editable or re-assignable by the assignee isn't an option because anyone should be able to re-assign tickets if the assignee is home sick etc.

I think the problem here is that you don't have a process that makes it clear who is working on something, which you can't fix in software

That's objectively wrong of course. We could argue about which solutions would be better but there have been good and well-performing options around for more than ten years now. Confluence has its collaborative editing and ServiceNow and every chat program out there lets you see when someone is typing a comment.

That said, there seems to be one plugin that tries to address this issue, although I haven't tried it myself.

Mmm, again, you haven't read the points above.  What counts as "looking at an issue" is the most important one.

The point about you not having a process is objectively correct I'm afraid.  Until you can answer the question about "what counts as looking", you can not form a process that can correctly tell everyone that someone else is looking at it.  And the problem with answering that question is that it is nowhere as simple as you think.  

As I said before, does it count if someone has your issue on-screen?  While they're off making coffee (or worse, working like me - open a browser window and then spending an hour playing with the cat instead of doing anything about it).  Or in a search result that includes it?  Or has a dashboard open with the issue being one of the results being displayed?  What if I'm writing a comment or update in Slack or email instead of the UI?

It is objectively (and subjectively for that matter) to say that you don't have a process that can clearly identify that someone is working on something.

Suggest an answer

Log in or Sign up to answer
Site Admin

Atlassian Community Events