Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to assign an issue to multiple assignees


Hi I am Ramya. I am new to JIRA. Please advise me how to assign an issue to multiple assignees.

4 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question


You cannot assign one issue to multiple assignees. It is an impossible thing to do in Jira. Because this is against the principle of how Jira operates. If you assign one issue to multiple people, the responsibility of the issue will be vague and not clear. That's why you cannot do it.

However if it's very crucial, you can create optional configurations. For example, you can create a mail group that consists a group of people, create a user with this mail group on Jira and assign the issue to this user. But I would not recommend such a thing because of the reason I explained above. 

If you explain the business reason why you want this, maybe we can find another solution that would fit your needs.


As a tester I assign an issue to the developer and I would like to send the status of the issue to my TL and PM also as a notification.Please suggest.





As @Niklas _bitvoodoo_ suggested below, you can use watchers feature of Jira. Check out this blog post about watchers and mentions. If you want your TL and PM to get notification every time the issue is updated you can use watchers. If you want them to get one time notification you can use mentions.

Other than that you can create issue filters for more than one issue and other people can subscribe to these filters to get timely notifications that you manage.


Like # people like this


Thank you for your support.

I am not able to understand from the above information.Could you please explain me step by step how to create watchers .




The ability to assign multiple task owners should be added to Jira, agile scrum at a minimum.

Collaboration is enshrined in both the agile manifesto and scrum guide and part of the DNA.. shared understanding, shared ownership, the best ideas come from developers and the business people working together daily, and the list goes on.

Shared ownership is a good thing! Beyond the active build stage, shared ownership can also be seen as shared recognition when a piece launches. 

This would also enable stakeholders to have contingency or backup for a POC or if the previous task lead left the company.

In other applications where scrum is used for example Creative, it would be very beneficial for a landing page for eg. to be lead by both a writer and a designer. It feels like Jira is pushing a hierarchical approach.

Gotta respect the core agile principles and values if you expect people to use a product that labels itself "agile" & "scrum" prominently.

If it fundamentally or theoretically contradicts with something, why not just add it as an a settings toggle? There are settings for a million other things in there already!

I think you've completely missed the point here. 

This sentence says it all:  "In other applications where scrum is used for example Creative, it would be very beneficial for a landing page for eg. to be lead by both a writer and a designer."

Scrum says nothing about assignee, in fact, in your example, it directly says that you should not have a story that is "lead by a writer and a designer".  The story is the responsibility of the development team.  Not one or many individuals within it, the team is responsible.  (And you know who the team is because the issue is in their backlog or on their sprint board)

Like Niklas _bitvoodoo_ likes this

@Nic Brough why would Jira agile scrum have assignees at all then? In your thinking, each ticket would just be assigned to "Team" and this is absolutely not the case. Jira offers assignees, but only one.

There's tactical value in having multiple assignees noted in my original comment and fundamentally, you and jira overlook the tactical value owning something together.

This feature would foster better teamwork, especially in the more work-from-home world we now live in.

And remember, scrum is getting more widely used (applied) across various industries. If Atlassian expects its software will stand the test of time over the long-term then it should inspect and adapt based on what customers are asking for. That also is a key piece Atlassian is overlooking here - Give value to your customers, not your internal, theoretical, software-only myopic view holders.

Like # people like this

You're right, Scrum doesn't need assignees at all, and we often find (healthy) scrum teams drop the field.

Jira offers a single assignee by design, and has done for a long time before any boards for supporting Scrum and Kanban were implemented in it.

It is designed that way because you should never never have multiple assignees.  In all industries, in real life, multiple assignee does not work.

I've spent years sorting out the messes made by people implementing mulltiple assignees, and in some cases, this has been done by migrating away from systems that allow it on to more sane systems (including Jira) that explicitly do not allow it.

In many teams, pair programming is a thing and working on a bug in a pair is also helpful - also let's say there is a novice in the team and he need a help in the first two months with the tasks - with your logic in the board there should be task assigned to the new boy and a separate task assigned to the one, who's helping him.

In which scenario does that make logic to you and is more transparent? All you add is stupid excessively complicated administrative procedure to do simple thing.

So you should have multiple assigners, in some industries, in real life, multiple assignee does work.

Like # people like this

You don't need multiple assignees in pair programming either, the people doing it will have worked so closely together, it doesn't matter which one you assign it to.  And you can simply add a field for "other part of pair" if you really really need it.

In all other cases, multiple assignees will let you down.  It is of no use in real life, and I can guarantee you it will cause you problems.

There's no point in repeatedly making false assertions while ignoring the main point.

Multiple assignee does not work.  It is not implemented in Jira because it does not work.  That's all. 

Has there been any movement on this? The participants and watchers are great if you are keeping an eye on certain issues. However, sometimes multiple tecnicians work together on the same project/task and it takes several hours to complete-- this only allows time credit due to one technician for that task. 

If anyone else is also concerned about this-- I have suggested the techs to link tickets to the original request in order to record their time working on an issue. Of course, this woudl only apply to longer projects.

However, it would be great to have multiple assignees as an option so that the "Linked" tickets don't bring up the ticket count.


Thank you

There is no movement to be made - you do not want multiple-assignees and Atlassian are not going to implement it, they closed all the requests with "won't do".

What Nic said, when you assign a ticket to a technician that person becomes responsible for it (open to close) which is the principle that is reinforced in JIRA.  If you have someone helping them, you could create a sub-task of that main ticket and assign that to the helper and put all their work/time on that sub-task which stays under the main task.

Like # people like this

This entire argument neglects the fact that pair programming is a widely spread practice and JIRA basically becomes useless in tracking the pair currently working on a ticket. I hope Atlassian reconsiders their 20th century opinion on this topic

Like # people like this

That's the one tiny edge-case where it has a valid use case.  But the nature of pair programming makes it pretty much useless - it doesn't matter which one of the pair it is assigned to, and if you really desperately need to record both, add a select list for "other person"

I don't think anyone would want to open up software for vast misuse just for one edge case that has a simple way to "fix"

Teams are misusing Jira already on a daily basis, I don't think throwing sticks between the legs of people who have legitimate use-cases for a feature is helping anyone. We now just use Github Projects for my team. We have GH anyways and it allows us to properly visualise the pairs on the board. I just wanted to share that Atlassian is actively losing customers over this while the rest of the industry is moving on and focuses on enabling teams instead of blocking them. This "other person" fix is also hardly a fix at all. It's basically a useless feature which doesn't even show up on the board but is merely helpful for reporting cases which is a misuse of Jira, IMO.

Like # people like this

I think it's better to "stop people breaking stuff for the vast majority of usage" and accept that "a tiny handful of users have a minor inconvenience of having to look in two fields on the rare time it matters" is a better compromise.

"Single point of responsibility for an issue" is actually something that crops up more than you are thinking, and because Jira does it properly, it helps get it selected as the replacement for the broken system that allows it.  Although I can't complain too much - "sorting out the mess made by allowing multiple assignees" has generated quite a lot of work (including migrations to Jira) in the past.

I do not think it is possible to find any justification for "we're perfectly happy to let people use 'I thought someone else was doing it' as a valid excuse for failure to deliver".

The "other person field" is less than ideal, but like I said, it's a tiny handful of people that use it.  What I often see for pair-programming is "assignee = the pair's team-lead or boss, with a multi-select field for the two in the pair", because that's often a more useful point of responsibility.

I think the take away for me is that Jira optimises for corporate environments where hierarchy and control matters more over self-organised teams where visibility inside the team and trust in a flat hierarchy is a given.

Like # people like this

I'm not sure that is a correct view to be honest. You still have the ability to visually see everything and assign work to anyone you want. In addition, you can create sub-tasks that serve the same function for "tracking time" but keeps it all under the main task.  I can see where in some teams having multiple people working on something is good but there are ways to still track the work both overall and individually.

I don't think it's quite right either.

A self-organised team, from the outside, no, doesn't technically need an assignee on an issue.  You could argue "the whole team is responsible", and that's fine for well-functioning self-organised teams.  Internally, though, if a team is not working perfectly, how do you stop "I thought someone else was working on it?".   Single assignee is the only option.  And it protects the team from "well that team won't tell me what's going wrong" and "I need to know who is responsible for..." at the corporate level.

Jira is highly optimised for self-organised teams.  "Multiple assignee" is optimised for multi-level failures and nothing else.

Meh - a team not working perfectly could just as easily have problems with individual assignment. "It's assigned to me but I am not working on it and have nothing to do with it"

Or, "we don't know who to assign it to so we'll put it in this unassigned bucket that no one cares about"

In many cases there is shared responsibility on our tickets, and any one in the shared responsibility group can speak for the ticket.

Like # people like this

Yep, but the point there is a well-functioning team won't need to pay much attention to an assignee field.  They certainly won't even begin to think they want a multiple-assignee field.  Team ownership of issues would be done elsewhere (for example "it's on our board")

Not so. For example we like to count capex hours per person. So several people assigned to one ticket would be a nice possibility.

Two people moving a piano - why does one have to be assigned to the ticket when both workers are doing the work? It's sort of nonsense to me the idea that the piano can't be moved otherwise.

Like # people like this

See above - you don't measure expenditure by assignees, the most obvious thing to do is measure it by actual work logged (you don't have to be the single point of ownership to log work on something)

And for the piano - "I thought the other one was doing it".  That is the monumental nightmare that multiple assignee lands you in, and any halfway decent process demands you never do that (also as repeatedly explained before)

I disagree and so do many others.

The Jira log work mechanism adds hours to the current assignee.

A group design review can very well be represented as a task. It has many people. The process isn't indecent just because there's no sense in tagging some arbitrary person of the group as an assignee.

Similarly there are times when many people are investigating a high pri issue together. There's no sense in making a ticket for each of them.

There are times when there is individual responsibility for a ticket, and there are other times when groups collectively share responsibility.

Like # people like this

Nope, Jira work logs are added to issues by separate people, irrespective of the assignee.  You may have configured yours with permissions that say "only assignee can log work", but that's absolutely not the defualt.

Your example fits perfectly into all the stuff discussed above.  I'm not going to repeat it again as you choose to ignore the main point - "I thought someone else was doing it".

Susie (above) isn't concerned about the risk of "I thought someone else was doing it" and neither am I.

I landed here because folks I work with had asked me if Jira would ever support multiple assignees, and, like Susie, was hoping there was a solution or progress towards one.

The answer is clearly 'no' but the rationale looks more like it got designed into a corner, than a real reason.

Like # people like this

The rationale is to prevent people getting into a mess with "I thought someone else was doing it".  It's an anti-pattern, it's a disaster in most places (in some heavily regulated fields, it's even illegal, with good reason).

So, yes, you've found your answer - Jira doesn't do multiple assignees, never will directly, but does have lots of way to do "and these other people/teams/things may be involved", and Atlassian are actively improving on those.

It's funny how you mention that the time logging is configurable but the assignee is not. It feels like all arguments could be applied to both features. Why is the time logging configurable, but the assignee is not? Fair enough if some airline company or financial company has regulations coming in from above but most digital companies _do not_ operate in such a highly regulated area. Why does some food delivery or furniture company have to obey to the limitations of those regulated industries? Why can't this be configurable?

The whole argument _does_ sound like what Jim was saying:

>The answer is clearly 'no' but the rationale looks more like it got designed into a corner, than a real reason.

The product was designed around this and it would not be possible to change Jira in this regard and the whole "ambiguous responsibility" argument is simply a straw man.

Like # people like this

>It's funny how you mention that the time logging is configurable but the assignee is not. It feels like all arguments could be applied to both features. Why is the time logging configurable, but the assignee is not? 

Time logging and responsibility for an issue are two totally different things, with different purposes and reasons for existing.  Comparing them in the context of this discussion is not relevant.

>the whole "ambiguous responsibility" argument is simply a straw man

That statement there is a straw man - you are now misrepresenting the core of what is being said - multiple assignees does not work (for many reasons, the main one being it allows "I thought someone else was doing it")

All I want to do is: just look at my Sprint or Kanban board and see who is working with whom on which task at any time. That's it. Can Jira do that, or not?

I don't care if there has to be a single person in charge or if spent times are somehow tracked automatically.

The only thing I would like to see is all the faces of the people actually working for a ticket, as a picture on the ticket. And if 4 developers are fixing an important bug all together at the same time, I want to recognize it immediately looking at the board.

Just to have clarity and transparency at any time.

And I'm certainly not the only developer, scrum master or whatever who would like to have this feature and I wouldn't be so sure about "a tiny handful of users"...

Like # people like this

Hi @Ramya Pendem

@Elifcan Cakmak is totally right, this is a thing against Jira's principles. 

Work instead with watchers or if working with Jira Service Desk with request participants.


Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question


Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you