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

Why can't we have multiple assignees on a ticket?

I'm asking this as a question and not a discussion because I want an answer.

Jira is a big complicated app and sometimes in a big corporation with many stakeholders it can be a tough sell.

What doesn't help is when there are arbitrary decisions made like "a task can only have one assignee". I've worked in multiple software companies and EVERYWHERE that I have used Jira the same problem is always floated.

"Why can't I assign two people to this ticket?"

When I explain that you just can't, and I don't know why then the eye-rolling ensues.

The amount of discussion around this one particular feature on this forum and on the internet as a whole is very indicative of the the fact that this is a hot topic.

So here's my own personal question:

Why is this arbitrarily locked down when the number of labels a ticket can have isn't? The number of child tasks that can be assigned isn't etc etc. Why does Atlassian force the law on this one particular feature but give maximum flexibility everywhere else?

Surely if in my organisation I see fit to assign a ticket to two people (or three or four) then I should be able to do that.

If you're one of the militant "one assignee per ticket" people then that's fine. You do you. Everyone else should have the choice.


Sorry @Lenin Raj Rajasekaran but no - that's not a solution. It's a horrible, complex workaround involving the creating of email accounts (usually another department) creating new jira accounts (adds cost) and generally its a fuddled mess.

One day person X and person Y may be working together. The next week person Y might be working with Person Z. Are we supposed to go around that process each time? It's simply ridiculous.

The thing that REALLY gets me:

"it creates a problem with accountability" - You SHOULD NOT be defining or assuming how accountability works at every company in the world who chooses to use Jira. How my company tracks accountability is not Atlassian's problem.

So no - you have not solved this problem and given that you have acknowledged that it is the most asked for / most requested feature it's quite simply disgraceful that you haven't come up with a real solution.

Like # people like this

Or... Atlassian could just listen to customers and allow multiple assignees per ticket? Is that too crazy?

Like Lenin Raj Rajasekaran likes this

The majority of the customers really really don't want it.

This is an argument that has rattled on for years, even to the point where three people who were proponents of multiple assignees have ended up spending a lot of money with Partner or contractor support gradually unpicking the messes they've made of it.

There's nothing wrong with "associate" assignee(s), or "group generally responsible", but in the real world, multiple assignees allows for "I though the other one was doing it", and that is always a nasty mess when it happens.

Like Lenin Raj Rajasekaran likes this

@Nic Brough _Adaptavist_ "The majority of the customers really really don't want it."

Do you have any data to back up that statement or is that simply opinion presented as fact?

Also don't you think that the fact it has prattled on for years and years and doesn't show any sign of going away tell you something?

Like Lenin Raj Rajasekaran likes this


Over 25 years, I've yet to find anywhere that it works.  I've found lots of places that desperately needed to stop doing it, several Jira sites who (including, as I said, ones run by people who, in other threads here, thought it was a good idea until it blew up in their face - one of them had the decency to apologise in person and buy me a thank-you-for-unpicking-the-mess pint).

I am still waiting to see a decent answer to "what if the other person said they thought the other people were responsible".  Whilst that's not "evidence", it is a fact, and human nature pretty much guarantees that it is going to happen.

The fact it has prattled on for years is also human nature.  There's loads of things that prattle on for years with the people who are wrong just not getting it but being vocal about it - we still have astrology columns in newspapers, anti-vaxxers, climate change deniers - just because they're loud or common does not mean that they're right (or even that the opinion is valid - it's not an opinion when it's wrong).  I'm not saying there that "multiple assignees" is not a valid opinion - I'm picking exaggerated cases.  But multiple assignees does fail in the real world (with one exception, where it works fine, but has incredibly limited use and is fixed by adding a user-picker field to Jira)

Like # people like this

I think the use case is different. I don't have your 25 years I only have 12 but everywhere I've worked I hear a regular chime of "why can't you assign multiple people to a task". And I think this once again boils back down to that universal concept of "people are different".

In the team I look after almost all work is done in pairs and mobs. I find the "assignee" mechanism extremely useful for looking across the board and seeing who is on what. It's not about accountability or ultimate responsibility - I don't run my teams that way (again - different people do different things in different ways... shocker), it's about simply knowing who is on what.

Right now if suzy and steve are working on a task I can look at the board and only see suzy's avatar on a ticket. Unless I remember that steve is also on that task then I need to ask around. Magnify this by 12 teams and you see why this would be useful for me and many others who may have different requirements again.

What this ALWAYS boils back down to is that different people operate differently. Take that fact combined with a few other facts:

1) As you said yourself this argument has been happening for years and isn't going away

2) Atlassian themselves have admitted this is there most requested feature

and what you have is a basis for implementing this.

I don't mean to sound disrespectful or impolite but how you work is completely irrelevant to me and the thousands of other people who want this feature and could make it work for them in their specific use case.

Like Alisa Ströbele likes this

You know... for a community of what is obviously a group of intelligent, problem solving people, the amount of 

"Well i don't want this feature so therefore nobody should want it"

is really really surprising.

John Funk Community Leader Jan 15, 2020

@Mick C  - You keep throwing out that the comment that "Atlassian themselves have admitted this is there most requested feature", but I think you have confused a comment by another user that the question is one that particular user gets most often. Please do not confuse the two. Community Leaders are not Atlassian staff. We are users just like you trying to help other users. 

You work differently than the majority of us. We get that. But that doesn't mean that Atlassian should provide you with whatever you want. You have been given workarounds to accomplish what you want. That's not always available for lots of features that many of us would like to have. I am sorry that you don't like having to use workarounds. I get that, trust me. But at least you can do something. 

The Community here is not the place to try to brow beat Atlassian into providing what you want. Please open a support ticket with them.  :-)

Like Nic Brough _Adaptavist_ likes this
John Funk Community Leader Jan 25, 2020

@Lenin Raj Rajasekaran  - Do you know if there is an open request to provide this functionality? If so, can you provide a link so that @Mick C can vote on this?

AFAIK there is no open ticket for this request.

Many tickets for this have been created.  They have all been closed with responses that say it does not work. 

In my opinion a ticket should have one assignee (=accountable person) at the same time. 

Surely a task can have different assignees overall. However, in my opinion the exact same task cannot be owned by multiple people at the same time. You are free to change assignees as the statuses or circumstances change.

Let's say you have got a ticket in order to create a login for some new employee. This can only be owned by a single person. It is just a single person task. In the second you give the opportunity to assign multiple users to that task, you also eliminate the accountability of the field. Also the assigned users will most likely just rely on the other assignees. 

As I said above, in my opinion it makes more sense to change the assignee as circumstances/statuses change OR just divide the task in multiple smaller tasks which again have got one assignee but actually realize one big task. Let's say you and your team have to create a documentation for your new application. On the first glance this is a single task but actually multiple people will contribute to it. So you should divide this task into what actually has to be done by the single team members. 

Well, this is my personal opinion. 

Like # people like this

And this is absolutely fine :-)

Your opinion = great. However many many others have a differing opinion which is also fine. My point is exactly relating to what you've said; you do you.

However if you wish to be able to assign multiple assignees to a task then you should be able to.

Like # people like this

Okay, I see your accountability comment above and I agree. No one from outside can judge how accountability in your very own company works.

Like Lenin Raj Rajasekaran likes this

I agree with you.


I suspect this is because Jira does not update the issue you are looking at in real time.

If multiple people are viewing an issue, the "newest" change to a field is the one that sticks, so a group of people can not work on a single issue.


If Jira would support multiple simultaneous edits(like Google docs etc.) I think this would have been a feature long time ago.

How would you stop "I thought the other assignee was doing it" becoming a problem?

In my world multiple assignees would only be assigned to pairs and mobs, so this wouldn't be an issue.

The key thing here is the "in my world" statement. I understand that different companies and teams work in different ways and if someone was to assign the same task to two or three people who were in different parts of the office, or in different offices then this would be a problem.

However this is a MANAGEMENT ISSUE and it's not for Atlassian to dictate how teams are run or how companies deal with accountability.

@Jack Brickey That's a good point, but making it available for teams that don't have a "I though the otherone was doing it" problem would not bother me at all.

This is the bit that my anecdotes are all based on

You say "teams that don't have a "I thought the other one was doing it" problem".

Show me one of those and I'll show you a handsome invisible pink unicorn.  Granted, some teams are better than others, and many superb, but it will happen, in every team, eventually.  The question is not about "probably won't", but about "cannot".

(My one exception to that is an active pair-programming couple, where it won't happen, but doesn't matter anyway)

Two people sitting next to eachother, actively discussing how they are going to work together on an issue, documenting who is doing what.

Ah, that was my exception.  In this case, you don't actually care who the assignee is.  As soon as they stop working together, the problem can happen again.

John Funk Community Leader Jan 27, 2020

And out of the thousands of users in Jira - how often does that happen?

Oh gods, wrong time to ask.  I'm on a course this week with 20 other expert Jira admins.  The instructor found a really odd thing in the data as we started one of the exercises, and almost broke down and wept when he say a mapping for multiple-assignee with a jira custom field.   The entire room sympathised - we've all got many horror stories about just how bad a thing to do it is.

@Viktor if 2 people are discussing how they are working together on an issue and documenting - doesn't that mean the issue itself can be broken down? What you describe is 2+ issues. Even if 2 people are editing an issue in real time they are doing different things.

@Mick C how does it work in your world? No 2 people can be doing the "same" thing at the "same" time? I'm curious about how that works. In reality it doesn't? If 2 people are assigned on a big task, then why not just break it down? If 2 people are assigned on a small task, why? I don't understand why you'd need 2 people to fetch the toilet paper for example. IF in the example that there are a lot of toilet paper and it requires 2 people then you are requesting 2 tasks, so there should be 2 and 1 each.

Even in some pair programming world the 2 aren't doing the same thing at the same time. 1 is mentoring, debugging, documenting or something else whilst 1 is coding. Unless they're both typing on the same keyboard etc.

Like John Funk likes this

Still waiting for any single example where it might work.

Jack Brickey Community Leader Jan 13, 2020

Hi @Mick C , you might want to consider sending in a suggestion via Atlassian support for this. The most important aspect would be to articulate the detailed requirements. Things to consider:

  • is two enough or should the implementation be “n” assignees?
  • notifications - is a single notification scheme sufficient for all assignees or would you require unique schemes for each?
  • reporting by Assignee - there are a lot of implications on how gadgets and reports work leveraging Assignee field. How would you want each to behave in the various reports/filters/gadgets?
  • Would you want a single Assignee field that can contain multiple users or would you want unique Assignee fields (e.g. Assignee, Assignee2, Assignee3...) that could be filtered on independently?

you might also wish to check at and search for existing suggestions and if found vote/watch and add comments there.

Finally, and I’m sure you are already aware of this, you can always create a new “second Assignee” user picker custom field. However, it won’t behave like the Assignee field with any special rules. You could consider marrying the custom field with a scripting/automation addon to give you some of those behaviors.

Like # people like this

Appreciate all this advice. I've read all the arguments all over the internet (well not "all" but a significant amount) about this issue and my point is moreso relating to the staggering amount of demand for this functionality.

Rather than Atlassian listing all the multiple workarounds, why won't they just implement multiple assignees to tasks?

It should work just like the single assignee works.

Like Lenin Raj Rajasekaran likes this
Jack Brickey Community Leader Jan 13, 2020

I can’t answer for Atlassian at all here as I am just a user like yourself. That said I know there are a ton of request for product changes. Some I’m sure make sense and align with the product architecture and strategy and some I’m sure do not. I can’t say where this request would fall. I only know it isn’t something I would want/need but appreciate that others may. 

Like # people like this
John Funk Community Leader Jan 13, 2020

I will weigh in that I think it's a really bad idea to have two people assigned to an issue. We treat the assignee as the owner of the issue and they are responsible until someone pulls the card from them and takes ownership. That's more of a Kanban best practice than anything. 

If you find you have multiple people working on a single issue at the same time, there's a good chance the issue hasn't been broken down to the smallest level it should be. 

Those are my two cents.  :-)

Like # people like this

I completely understand however the overall point i'm making is that whilst that's how you think it should be done, there are many others who don't think it should be limited in that way. There are many use cases where it makes sense for the company / team involved.

All I'm saying is.... You do you and let me do me.

However Atlassian is laying down the law on this one and I just would like to know why. As you can see from one of the links above, this is recognised by Atlassian as their most asked for thing. So why are they not delivering it?

Like Lenin Raj Rajasekaran likes this

If overall accountability is really a concern and is really the reason Atlassian have refused to implement this then I'm really underwhelmed by your Product and Engineering talent.

Make the first assignee the "primary" or "lead" assignee. There you go, accountability problem solved.

Like Lenin Raj Rajasekaran likes this

@Mick C by this logic of those who don't think it should be "limited" in that way -- why are we limited to anything? 1 person should have multiple avatars? An issue can belong to multiple projects and multiple Epics. Let's just rip out all the rules right? How does having multiple assignees make sense? Unless no 1 is working. In what scenario does and can this happen? Just have a task that says "Do work" and add everyone in the team in? If so why use JIRA?

Like John Funk likes this

Short answer:  It.  Does.  Not.  Work.

How incredibly arrogant and small minded.

Like Viktor likes this

Yes.  I accept that.

I know that I am not a good writer.  I know that I write stuff that comes across as abrasive, aggressive or (and) arrogant.

I stand by "multiple assignees does not work".   But you are absolutely right that the way I said it is arrogant. 

"Small minded" is a different matter though.   I have imagined things that horrified science-fiction writers and kicked them into writing books and film scripts that win prizes because they are so twisted.  

Having spent 25 years of watching "multiple assignee" fail on every level (even the few it might, in theory, work for), I do want to object to that.

Let's try it the more useful way around.  Please could you show me a system that allows two or more assignees where "I thought the other assignee was doing it" can not happen?

Actually the very first thing I tried lets you assign multiple "owners" to a task. - seems to be the new kid on the block and it seems that they get it.

See the video here:

Now let's go look at their pricing page....

Also - the "task owner" column is configurable.

It's almost like they understand that different teams and different companies do things differently.... crazy!

Screenshot 2020-01-20 at 12.02.03.png

And here we are in Kanban mode

Screenshot 2020-01-20 at 12.39.01.png

Jack Brickey Community Leader Jan 20, 2020

Mick, it seems you have found the tool that best fits your requirements. I’m not sure that how something works in one tool translates to another tool being wrong. There are many tools out there in this space with many similarities and many differences. Competition and choices is a wonderful thing for obvious reasons.

if I can rewind back the the original post, you indicated that you did not want a discussion here but rather you wanted an answer. I think that the answers have been provided and this post in fact is a discussion at this point. At this point should we move to the discussion forum collection?

Hi Jack, I didn't say anywhere that "how something works in one tool translates to another tool being wrong" - I really don't know how you managed to interpret anything like that.

I was asked by another Community Leader to show another tool that allows multiple assignees and that's all I did.

Like Lenin Raj Rajasekaran likes this

Yes, I've currently got two projects running away from because of the mess made by multiple assignee.  Thank you for the evidence.

Like John Funk likes this
John Funk Community Leader Jan 29, 2020

Hey @Mick C  - Here's pretty much the bottom line. There are NO open requests with Atlassian to add this feature. You should put one in if you like, but it sounds like it will go the way of the others that have been closed already. It is NOT the most requested feature asked for from Atlassian. 

You can use the workarounds suggested to you, or you can put in a new request for the feature. Then people can vote for your idea if they want it. But whining here will not change a thing. You are using up the time of other users that can respond to other needs and help people that want to be helped.

Sorry if that sounds arrogant or mean or whatever word you want to use. But you are going to get nowhere here with the rantings. I truly hope you find some peace about the matter.  :-)

Several years ago I;ve used jira where was installed some really handy plugin that allowed to set a list of co-workers on the ticket. Now I need it again but can't find it... does any body know where is this awesome co-worker thingy hiding from me?

Actually, yes, I think I've worked with the app you are talking about.  It died because

  • You should have a single assignee
  • It's a good thing to nominate other people, groups or roles as the secondary points of contact, but you can do that with custom fields, you don't need an app.

This is an issue for me - we are a small team of three that need a system of notification for tasks and sequential production flow.  Stages 1-3

When the stock gets low, we get notified, whoever is available can accept or decline the task. 

When the job is complete, a new stage opens up and whoever is available can accept or decline. 

You'd think it was easy

It is easy.  One person (the assignee) is responsiple for the task in hand at the moment.  I'm not sure where you think multiple assignees might be of any use here?

It's true, that it only takes one person to actually do the job but it's subject to the users availability.  

The process is sequential, the assignee for each stage can be different.  (Opt in)


Log in or Sign up to comment

Atlassian Community Events