Create
cancel
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

Two assignee fields

Hi guys!

Can you have two assignee fields on a Jira Software ticket.

If not - what is the best way to deal with it if two people needs to look at the ticket at the same time?

I can add field for the Designer sign off but how do i assign to a tester and a designer?

13 answers

Hi @Vanessa Becker ,

 You can't have multiple assignee's as far as I'm aware.

It sounds like you may be better off adding an additional Status in the workflow for the Designer sign-off (therefore allowing it to be assigned to them specifically). You could also setup automation or workflow transition actions to assign to a specific person OR person based on component - for example.

As you say an alternative would be to put a custom field of a user picker to illustrate who your tester should get sign off from as part of your process.

Thanks

Lewis

Hi @Vanessa Becker ,

For such cases, we typically recommend using sub-tasks. For the Task itself, you always need 1 single responsible user (the assignee). Otherwise, if 2 people are responsible, no one is responsible... 

You can create 2 sub-tasks as children of the ticket and assign a sub-task to each of the two users. 

Regards
Mathias

Creating sub-tasks is the method we use to solve this. It's a clean process without any customization needed. 

Like # people like this

Having multiple responsible for a single issue does not give clear division of responsibilities. You can however, add a custom field to the issue screen which will let you enter one or more user names, hence achiving the desire to relate two or more users to an issue.

It depends on an issue. I can imagine a task like update 5000 records in DB that can be done by two DB admins in parallel. One can update 2000 and the other - 3000. Creator can be not aware who does what, he does not care, he wants the task done. Subtask is also not practical - after both do their part who should close original task?

But which one is responsible for getting it done?  What stops either of them saying "I thought the other one was doing it".  You should never allow people to put themselves in a position where it's valid to say that.

Like # people like this

When I have issues like that I give clear instructions in comments section. E.g. Joe please do your part and then assign the task to Sam. Sam do your part and close the issue. We have history in jira and whoever breaks the rule will be punished :)

Thereby making the assignee field pointless, and responsibility really hard to track and identify.

Don't do that.

Yep you are right. For this particular situation of Vanessa I would create a special type of task, make two obligatory custom fields (Designer, QA), make workflow steps "In design", "In test" and make two rules that will assign the task to Designer field value when it is transitioned to "In design" and to QA when it is transitioned to "In tests". It will take me 15 minutes to finish and test it all.

Like Nic Brough _Adaptavist_ likes this

@Vanessa Becker 

Create 2 different custom fields of type 'User Picker (single user)', name them as "Designer" and "Tester". Add them to screens. Don't forget to add them to notification schemes. 

You can also use User Picker (multiple users) custom field

Hi @Vanessa Becker

we answered this question in one of our articles a while ago. Feel free to check it out here: https://www.actonic.de/en/assign-jira-tasks-to-multiple-users/

We also have a beginners guide for Jira, if you are interested in that: https://www.actonic.de/en/introduction-to-task-management-with-jira/

Hope this helps. :)

 

Best,

Andreas

Cool, an instrument to make your product higher in google search results. The thing is that we need answers not links.

Like # people like this

This is not about any product, it just didn't seem to make much sense to copy and paste our entire article here.

Sorry if it offended you, please just ignore.

I looked at your post history @Andreas Springer _Actonic_  and this was the only link I saw.  I believe that you are not trying to build links on this platform but the conflict of interest apparent in your role and this post/your other posts takes away from what might actually be helpful info.  "Not about any product" rings hollow in that context.  

I don’t think that the article linked to by Andreas was pushing a product. I’m not sure where Sergei got that idea from. And Joe’s comment doesn’t help because Andreas is clear about being an Atlassian partner.

Let's stick to the original question here, please

Like # people like this

You can have several fields where you can pick a user (or several users even)

Then you can name these fields however you like, but they will not be the "Assignee" field in Jira

This is how we manage QA Assignees - assigning an issue to our "Ready for QA" status or the custom field being filled in triggers a notice to the QA assignee's email and/or the QA team's slack channel. 

From a Lean-Agile Team perspective (cross-functional, self-organizing), we want to avoid "hand-offs" from one person to the next, especially via tools.  However, the "Assignee" field in Jira has a long legacy of meaning pretty much that!

Consider a new custom field "Invitees" (multi-user), with description: "People to invite to peer-work on an issue".  Anyone who is peer-working on the issue is put into that field.  And even before that (say during Backlog Refinement), folks can add themselves to issues they would like to work on.  The person who eventually "pulls" the issue also invites the listed Invitees (who can still opt out).  We can also avoid a couple classic problems with a traditional mindset: "pushing" (assigning) issues to other people, or "reserving" an issue to work on later.

If you want to add other participant capacities, consider additional fields like "Consultees" (multi-user), with description: "People to consult on an issue".  They might be on the Team or even anyone else in your company.  Folks can add themselves to issues (say during Backlog Refinement) that they know something about, but do not necessarily need/want to work on directly.

Beyond that, IMO the value of additional user fields starts to diminish, and potentially starts heading back into silo/hand-off land.  At one org we have a "Testers" (multi-user) field, with description: "People to test the resolution of an issue".  A lot of the testers / validators happen to be outside the Dev team, and have bursty work of their own, making testing somewhat asynchronous and intermittent.  Not an ideal set-up, but something to work on going forward.  And the Testers field is tiding us over in the meantime.

The Assignee field is special in Jira.  We do not want to have it hanging around unattended, and possibly misused.  So, consider discussing with the Team to repurpose that field to mean something more general, like "Owner" or "Shepherd".  The Assignee's job can be to ensure the issue flows through the workflow all the way to Done-Done (per the Team's Definition of Done).  In RACI terminology, think of the Assignee as "Accountable" but not necessarily "Responsible" (although they are likely also that too) for the issue.

1 vote

@Vanessa Becker -

In Jira Software/JSM env, you cannot have multiple assignees assigned to the same issue.  I agreed with @Nic Brough _Adaptavist_ I also disagreed with creating a custom field to host this concept.

I would recommend you to utilize the usage of Watchers/Requested Participants (out of the box) to handle this issue.  So the additional assignee can be alerted to the issues.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

I agree and think this is the correct answer.

I disagree and think this is not the correct answer.

As far as I understand Vanessa means that first designer works on issue and then QA checks his result and closes the issue. I conclude there should be a special workflow with steps made by designer and steps made by QA. For each of these steps we can assign appropriate person using Automation for Jira.

Your decision will make it hard to find what tasks should be done by Designer and QA respectively. They will need to check issues where they are watchers and look in comments. It takes much more time than just filtering by Assignee = myself and resolution is empty.

Like Anne Saunders likes this

@Sergei Gridnevskii -

My original input is simple without any additional customization required to address the ask using out of the box functionality.  You are right on one can customize the WF and switch the assignee at different transition steps.  You can also utilize Automation for Jira (assuming that user has the add-on in her env.

Best, Joseph

We use tasks or sub-tasks and assign these to individuals.

1. If you want to trick Atlassian create a group email for 2 or more employees and make 1 user in Jira. This works pretty well unless you don't care who personally works on the issue. E.g. you have a service and 3-4 guys that support it. Having one email for all is a good idea. And you pay much less for the license.

2. If you have a task that you think several people should work on, you may create a workflow that consists of steps to be done by one and other steps that should be done by the other. There can be an Automation rule that will assign second after transition to a specific state. This works well if you have a team that includes both developers and QA and you have states in tasks that should be done by devs and QA correspondingly.

3. (I prefer) decompose task to subtasks. Assign each subtask to a specific person. If you don't like subtasks - clone original task and set Blocked By link between two. Then assign each task to corresponding person.

I use all three approaches depending on project. 1 is good for services, 2 is for agile teams, 3 is good if you do not like complex workflows and prefer Open->In Progress->Done.

If you want to have two people to sign sth off you can look at adding an approval step to the workflow and require more than 1 person to approve it. Have a look at this article:

https://confluence.atlassian.com/servicemanagementserver/setting-up-approvals-939926369.html

Alternatively, as someone mentioned above split the task into sub-tasks if you need to track assignments as it's generally a bad practice to have one task assigned to multiple people (who is responsible in such case?).

it's generally a bad practice to have one task assigned to multiple people

It is a good practice if team consists of several people with different roles. E.g. Product Manager creates a task and assigns to Team Leader, the latter decides who will do that and assigns to dev, dev finishes and assigns to qa, QA checks and assigns to dev-ops to put to prod.

But if they can work in parallel - then task should be decomposed, you are right here.

No, it's really bad practice to have multiple assignees. 

It's fine to change assignees as responsibility over time can be different, but you should never never have more than one person as the assignee at a single time. 

And, yes, absolutely fine to decompose, or put "and other people may be involved" fields in, but the assignee must be a single person, the one who's responsible for making sure it gets done.

Another option could be to create a sub-task to track for example the sign-off of the second person and assign it to him. It really depends on how your team works and how the workflow is built, which info should be tracked and which kind of tracking you need (dashboards? agile board?). Each option could ease one or the other.

0 votes

If I am not mistaken you cannot have multiple assignee fields.

However you can create a custom field of type User and then eventually create an automation for the user to be notified when they are added to the issue.

Suggest an answer

Log in or Sign up to answer
TAGS

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