To get the latest and greatest features in JIRA, please upgrade to JIRA Software. Visit the Migration Hub for more information.

How do I assign issues to multiple users

JIRA is designed so that issues must be assigned to a single individual to prevent tasks from being overlooked. A team lead or manager should assign issues out to individuals, or your users will pick from a list of issues that they have the option to take on.

However, if you want to configure JIRA to allow issues to be assigned to multiple users there are a few option for doing so:

It is easy to still setup a queue the a group can pick from, or affiliate an issue with group in addition to having it assigned to an individual within that group:

Managing Issues via a Queue

You can configure your JIRA project to assign issues to an 'Unassigned' "queue" by default, which your users can then pick issues from.

To do this, set up the following:

  1. Configure your JIRA project to allow the 'default assignee' to be 'Unassigned' (see Defining a Project).
  2. Ensure that 'Allow unassigned issues' is set to ON in your General Configuration settings (Administration > Global Settings > General Configuration).
  3. Set any issues that you want to be in the queue to be 'Unassigned'.
  4. Create a dashboard page with a filter that lists all 'Unassigned' issues, share the dashboard page and request that interested members of the group display the shared page on their dashboards. See Managing Multiple Dashboard Pages for instructions.

Managing Issues via Group Ownership

You can add a custom field to store which users and groups should be associated with a given issue. This is particularly useful for projects where a team owns all issues of a particular type.

To do this, set up the following:

  1. Add a group picker custom field to your issues.
  2. Configure an email notification in your project's notification scheme to be sent to the 'Group Custom Field Value'.

An issue can now be "assigned" to the group by selecting the appropriate group in the group picker. An email notification will be sent to the group.

(info) Another option is to add a user picker custom field rather than a group picker, and assign multiple users to an issue. However, you will then have both the JIRA default user field and custom user field for your assignees.

Managing Issues via a User Account

You can create a JIRA user account to represent a group of people (e.g. 'developers') and assign issues to this user.

To do this, set up the following:

  1. Create a JIRA user to represent the group (see Managing Users).
  2. (Optional) Create an email mailing list for this group (not a JIRA function) and set the mailing list email as the JIRA user's email address.
  3. Create a dashboard page showing issues assigned to this user, share the dashboard page and request that interested members of the group display the shared page on their dashboards. See Managing Multiple Dashboard Pages for instructions.

An issue can now be assigned the new "user" representing the group and your users can track the issues on their dashboards. If you have set up a mailing list, your users will also be notified by email.

Managing Issue via Sub-Tasks

If you have a task managed by different users then you are able to break the combined task into individual subtasks with their own single assignees.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

38 Archived comments

  1. User avatar

    Greg Heap

    Regarding "Managing Issues via a Queue".

    What is described appears to be a "POOL" rather than a queue. It can only be a QUEUE if the issues are ordered. Perhaps you are assuming first in first served in which case it qualifies as a queue. If not, it is simply a POOL where no issue has precedence over any other.

    I have implemented a much more genuine type of queue using the plugin "Jira order plugin". This plugin allows the issues to be placed in what ever order you like. Unfortunately it is not compatible with v 4.4 and later and the developer does not look like he will update it any time soon and perhaps never.

    A genuine facility to manage issues via a queue would be a valuable addition to Jira.

    05 Feb 2012
  2. User avatar

    Jabari Deng

     the plugin "Jira order plugin" can be work in JIRA v4.4.4 I had test. although it's say not compatibility with JIRA 4.4.

    12 Feb 2012
  3. User avatar

    Jerry Huang

    then how about the case that the parallel task or issue (the content of the issue) that apply to both assignees?

    Let's say I have assigee A who is responsible for iPhone component while B is for Android. There is an new task (change request) apply to both platforms. Instead of inputting the same content twice, I would rather prefer that the item could be just assigned to 2 assignees. And only when both assignees resolved the item, we considerred the item could be closed.

    20 Feb 2012
    1. User avatar

      Kelvin Yap

      Hi Jerry, could sub-tasks work for your particular scenario? An issue for the change request could be created with work for iPhone and Android split into separate sub-tasks. Utilising the Sub-Task Blocking Condition in a custom workflow, you could prevent the parent issue from being closed until both sub-tasks are resolved.

      02 Mar 2012
  4. User avatar


    When managing issues via a user account be aware that email notifications will only be sent if said user account has "JIRA Users" permission (e.g. belongs to the jira-users group). See JRA-27860.

    12 Apr 2012
  5. User avatar


    Another scenario is as following: I have a task like "Refactoring", and all what I need from it is to collect time reports on refactoring during all the iteration from all the team. The task will be closed e.g. as the iteration finishes. I do not need sub-tasks, I need only aggregated time expenses. Will "group ownership" work for that case?

    07 Aug 2012
  6. User avatar


    When the issue is associated to the Group, can any user from the Group assign the ticket to themselves?

    29 Aug 2012
  7. User avatar

    Philip Schlesinger

    We're going the way of pair / mob programming.  

    If we create a user account for each 'pair' or 'mob', we will quickly exceed our user license.  

    If go the way of user or group custom fields, only one person will see a ticket on his/her list of to-dos.

    We could really use a feature where a ticket can be assigned to more than one person.

    25 Oct 2012
  8. User avatar


    This is a quick note on our desire to be able to assign multiple users to one issue.  We create sub-tasks whenever possible but there is one case where none of the above options are adequate.

    31 Oct 2012
  9. User avatar

    nicolas frank

    We do pair programming... true pair programming : this mean every day a pair of developer can decide to take a task and work on it. The composition on the pair can change at any time (1 dev move to another pair and another dev join the remaining developper.).

    Clearly, we want JIRA tasks (Stories, bugs, ...) to keep track on the people who worked on the issues and make them log their time... and clearly we have no easy way now : we just can't configure all possible combinaisons of pair using groups... Clearly for a true XP team practicing pair programming JIRA is not able to manage properly the XP process. We would need to be able to assign an issue to 2 people.


    19 Dec 2012
  10. User avatar


    When a parent case has 4 sub tasks , with 2 tasks per person, When i go to dashboard ,  and pull a report for one assignee , since parent can be assigned to only one( or leave it unassigned) , i only see the parent under one person . How can i have the report show the second person's tasks when i pull his report?

    Example parent task X and 2 of it's subs are assigned to john . Two other subs assigned to peter.

    On dashboard, i can view the parent and 4 subs under john( when i go to details , i sure see that peter has two of them)

    But when i go to peter , there is no trace or accountability for his 2 sub tasks.

    19 Feb 2013
    1. User avatar

      Matt Doar (ServiceRocket)

      If Peter is the assignee for two tasks, then you can query on assignee = Peter and will see those two subtasks. Don't restrict the query with an issue type.

      19 Feb 2013
  11. User avatar


    Thank you for the quick response.

    to be more clear , i use two dimensional filter statistics wih x axis - status and y axis - assignee. this way i click on each person when i talk to them and go thru all of their items. and in this case, when i click on peter, he does not show that parent X nor it's two sub tasks

    19 Feb 2013
    1. User avatar


      It all depends on the filter you saved and are using in the stats gadget. Check it doesn't restrict by issue type

      19 Feb 2013
  12. User avatar


    While I find JIRA to be a great product and find it more useful and enjoyable then some of its competitors, I do believe this to be a major drawback.  Where I work, we do a lot of pair programming and most tasks are split by front-end dev and back-end dev.  The solutions above just dont solve the problem.  Creating groups which change regularly just bloats the user base and more over tries to cover-up a short coming of the software.  We tried the sub-task approach for awhile, but found it to be more work than was necessary; adding 2 sub-tasks to almost every task purely for assigning users just bloated the task count and the work required to manage them.

    What we really need is a way to assign 1 task to multiple users.  Our company has recently started using LenaKit Kanban for its ease of use.  While I grumble at using 2 pieces of software to do 1 job, it does solve some of the drawbacks we face with JIRA.  I understand the desire to "prevent tasks from being overlooked", but feel it would be a nice option to allow the users of the system make that decision.  Default the system to single user assignment, which fulfills your intention, but give the admin the ability to override that.  Its about making the software flexible and empowering users imo.

    26 Feb 2013
    1. User avatar

      Matt Doar (ServiceRocket)

      You could define a custom field named "Pair Assignees" and make it a Multi User Picker field.

      27 Feb 2013
      1. User avatar

        TSO Logic Admin

        We are going with "Peer Assignees". (smile)


        17 Jan 2014
  13. User avatar


    This again does not solve the issue.  AS I have not tried this solution, I would suspect that if I search for issued assigned to me, any falling under this rule would be overlooked as they are not "assigned" to me.  You'd have to modify searches in order to also look at this custom field I suspect and that just smells of a hack, a workaround.  I re-iterate, the user/admin ought to be allow to override the default functionality to allow tasks to be assigned to multiple users.  This allows for a much cleaner and flexible solution.

    30 Jul 2013
  14. User avatar


    So for very simple tasks that everyone has to do, such as: Everybody read and sign the security briefing, what is the best way to do this? I'd be hapy with an automated sending of X tasks to X people, or a single task where %Complete was tracked by users that did it.

    09 Sep 2013
  15. User avatar

    Matt Doar [ServiceRocket]

    For simple tasks, a Confluence page with a checkbox per user often works. For really complex tasks, a subtask per user works. In between is a single JIRA issue with comments from people when they've done the task, or a Done transition that adds the current user to a text field so a list of people is built up

    10 Sep 2013
  16. User avatar

    Michael Fugl

    The problem we have is with recording worklogs. Every issue will be worked on by a different mix of people. If we assign to a super group then users find it hard to find the issues in Tempo or worse they log time to the wrong one. We can create filters to help the users so they see only in progress issues in Tempo, but we can't push these filters to their accounts and the filters will vary depending on the assignment mix.

    Also we can't hide issues in tempo until we close the project and we can only do this by changing the permission scheme. This means that we have to create lots of small projects rather than using the epic structure. What I would really like to do is assign a new issue to a set of people at the beginning, if it turns out to be a big one they can create subtasks alternatively we just add remove persons from the set. When issues are closed I should be able to hide them from Tempo. Tempo say this is a JIRA problem. Any suggestions?

    24 Sep 2013
  17. User avatar


    I agree with many of the commentors here - A tool should be there to help the team in whatever process works best for them - If the most efficient way for a pair to track their work is to share a story then the tool should allow it - creating a second story could be construed as just busy work which prevents folks from doing real work. I would very much like to see this shortcoming addressed and fixed.

    22 Nov 2013
  18. User avatar


    JIRA has some great stuff, but the agile part still needs improvement in order to conform to real life team work and not simple bug tracking. I have worked with a similar tool called TargetProcess. For each user story you can add multiple users per role. So you can actually add e.g. 3 developers and 1 QA. The minute a developer changes the status to ready for test - it will automatically show up on the QA user's dashboard.The only drawback is that it is hard to do resource planning for individuals, because the estimates are set per role and not per user. I would love to see this functionality in JIRA.

    12 Dec 2013
  19. User avatar

    Dustin Brown

    Our organization would LOVE to have this feature.  We used target process that allowed this and was great.  We often pair program a lot so having multiple users assigned to a task would be very helptul

    13 Dec 2013
  20. User avatar

    Saven Roybal

    Well, that's a little disappointing. Our team was just branching out into using JIRA to track issues other than bugs which are usually worked on in small groups within our team. Without being able to directly assign tasks to multiple members of our team, we're not going to be able to track who worked on what when. Oh well, at least I can stop trying to figure out how to do it.


    07 Jan 2014
  21. User avatar


    Leaving an issue as unassigned is not the same as 'Managing Issues via a Queue'. Was hoping that there was a feature by which users could define a queue (e.g. 'Business Analysis Queue'), so that a team of BA's could see work assigned to them and then pick up tickets when they are free.

    14 Jan 2014
    1. User avatar

      Matt Doar [ServiceRocket]

      You can always create an internal JIRA user named unassigned_ba and assign the issues to that user.  This does use up an extra JIRA user of course.

      14 Jan 2014
  22. User avatar


    The optimal solution for this would be if the default assignee for a component could be a group.  The default assignee system would rotate through the users in the group when selecting the assignee for the issue.


    16 Jan 2014
  23. User avatar


    I followed the directions for managing issues via Group Ownership as listed above.  The problem that persists is that when you go to the Issues Panel of a project, those issues stil show as unassigned.  Is there a way to modify the issues panel to show tasks that have been assigned to a group using this method?  Or is the only way around that to create the additional users with a group-type name?

    12 Feb 2014
  24. User avatar

    Mason Jones

    Sounds like it's been discussed and Atlassian feels strongly about ignoring this, but I'll just throw in another note that with teams doing pair-programming, the inability to have multiple assignees is almost a deal-breaker. Creating a "pair assignee" field is obviously a hack and breaks reporting and various other things without spending a great deal of time fixing it all. It's really hard to believe that there's no plan to add a simple "support pairing" flag in admin to enable this. Very sad responses about this so far, I have to say.

    09 Sep 2014
  25. User avatar

    Rich Adam

    This is a basic function that should be addressed by the JIRA SW.  I want multiple resources to be able to book time spent on a single issue.  Being able to assign an issue to multiple resources would allow this.  Creating groups and assigning them is a lame work around that skirts the issue.  A very weak response to this pretty basic request.

    JIRA is a tool.  It is used by me to manage my process.  Lecturing me about preventing tasks from being overlooked is simply a dodge from implementing (or having implemented) this simple extension.  Let ME manage my process with your tool.  I can enforce your single assignment idea myself by only assigning one resource if I wish to do so.  Some tasks legitimately NEED multiple resources assigned.  Restricting the functionality of the tool to enforce this dogmatic approach is making the tool weaker.

    19 Sep 2014
    1. User avatar

      Matt Doar [ServiceRocket]

      You could add a custom field of type Multi-user Picker and add the other users there. No groups needed.

      19 Sep 2014
      1. User avatar

        Paul Stallworth

        This comment needs to be moved up into the main article body as it is clearly the best option.

        18 Mar 2015
      1. User avatar

        Ryan Flores

        How would you display this info on an Agile board?  Typically when a story is assigned, that person's avatar will appear on the card.  Would your suggestion still allow us to display multiple avatars on the card?

        24 Jul 2015
        1. User avatar

          Matt Doar [ServiceRocket]

          I'm not sure if the multiuser picker custom field type is supported by the Card Layout editing feature in Agile. I don't think you could fit multiple avatars on a card but a list of users could be helpful

          24 Jul 2015
  26. User avatar

    Can not agree more with Rich Adam. We use XP and telling me as a agile tool provider that agile practices are fundamentally wrong is not a good statement to make for you.        

    04 Nov 2014
  27. User avatar

    Kevin Stark

    Most of the questions and comments above relate to tasks where multiple people are in the same role (developer) which is a requirement for true Agile programming. My problem is slightly different.

    I am a project manager and often have tasks that require multi-disciplinary group work during analysis and design phases of a project, involving a project manager, business analyst(s), an enterprise or solutions architect, database analyst(s) and software analyst(s). The organization I am currently working with is using JIRA for it's IT Service Centre and extending throughout the department, with the implementation of ITSM. The applications area is also using JIRA Agile for their work. The department also wants to implement resource management reporting processes, to guide its sourcing, recruitment and training plans. I am trying to determine if the information can be gained, as a by-product of the task management via JIRA, or whether some separate data collection processes need to be put in place.

    The only way that appears visible, is to create sub-tasks to artificially separate each contributor to the team/group work.

    Is there any other way of doing this is JIRA?

    08 Apr 2015
  28. User avatar

    Hesam Kamalan

    My QA lead is scratching her heir (as well as mine) and ask me why I cannot add follower to the task like what asana is doing?

    Honestly, this is a good feature if you can add it. thx 

    28 Jul 2015
Powered by Confluence and Scroll Viewport