Assign multiple assignees on one task

Here you go: Assign multiple assignees on one task
Long story short: this is not Asana’s vision, don’t count too much on it :sweat_smile:

1 Like

Hi @Brandon_Sanders and welcome to the Forum!

Thank you so much to share your feedback with us. As it stands, it is not possible to assign multiple people to the same task, and this is by design to ensure there is always a directly responsible individual. You can read more about this here

@Bastien_Siebman shared with you an existing thread we have on this topic. If you don’t mind I’m merging your post into it to gather all feedback.

Have a great Thursday!

1 Like

What about the use-case of two teams from two companies working together? I don’t know why you would limit the flexibility, it seems unnecessarily arbitrary. Because of this one feature problem, I will need to use Trello or an alternative.

Use case: When a task is completed by a developer, it needs to be reviewed by someone.

Here are some options:

a. Re-assign task to reviewer
CON: Person who did the task is now lost info. After review is complete, reviewer now must reassign the task back to the developer. This relies on each person knowing who to assign to next.

b. Add a sub-task for the reviewer
CON: This is tedious if you have to do it for every single task. Also, its not possible to filter based on custom fields from the parent task. E.g. If I want to sort all the work I have to review based on a Priority custom field in the parent task - not possible.

c. Add a plain text custom field called Reviewer where the initials of the reviewer are entered
CON: Doesn’t appear in that user’s My Tasks.
WORKAROUND: Each user should create a report for incomplete tasks with their initials in the Reviewer custom field.

d. Task copies
CON: This is tedious. I’m not sure if the tasks link back to the original, and what about all the other custom fields on the task…

I am currently trying out option C.

The solution IMHO would be to add a custom field type of a User. See Featured : Users in custom fields.

A good mental model for this is the many variations of RACI matrixes - responsible, accountable, consulted, informed.

R = Developer = Assigned to (single person following Apple’s DRI principle)

A = Product manager = The owner of the project the task is inside of (Asana lets you search by this - i.e. People > In projects owner by)

C = Another developer/tester = Sub task

I = Other developers/customer success = Task collaborators

1 Like

This is crucial to our workflow to be able to assign multiple people to one task to be able to delegate further (e.g., I would assign 1 task to both of our admins, and one of the admins would claim/decline the task based on workload). Following tasks isn’t good enough, and we absolutely do not want duplicate tasks as it just needs to get done, but it doesn’t matter by whom.
Perhaps the multiple person assignment could be a “pending” one, so that the individuals assigned to the task are required to claim or decline and if both decline, the person who assigned the task would get a notification?

1 Like

@Vaughan_Rouesnel (and @Shelby_Molyneux),

Might this work: When the developer’s work is ready for review, Create Follow-up Task (Tab-Shift-F) “Needs Review: <original task name>” which links to the main task and multi-home that task to a Needs Review project where all potential reviewers are project members. They will receive a notification of the new task; that’s the signal that one of them should claim it.

Another approach is to define a pseudo user if you would prefer to assign the main task or follow-up task to someone representing potential reviewers. You would have to one-time make an email address ( is what Gmail lets you do) and create the Asana account for that email. When ready for review, assign to that pseudo user and have a report of incomplete tasks assigned to reviewers, and/or use the follow-up with that assignment if you want some assignment.

I hope that maybe stimulated some potential solutions (workaround; whatever one would call them!).



1 Like

Yes. The intended rationale actually creates an even worse tragedy of the commons problem, the same problem the constraint is trying to solve, especially in software.

If there are two team members that could complete the task, I want them both assigned, so if one resource becomes available, they know exactly what task is ready to be worked on. It doesn’t have to mean that two people are working on it at the same time. The developer who is ready can “take” the task and simply unassign the other person, which perfectly communicates to all members exactly what is going on and what is next without an enormous barrier to entry.

None of the other methods functionally work, especially for small teams that don’t have hierarchies of PMs micro managing all resources at all times. A single assignee removes all the PRODUCTIVE responsibility and visibility away from other capable team members, assigned tasks lay idle as the owner is busy, while others who have nothing to do have, offline, have to ask what to do next. If they are senior, maybe they have the motivation to search through unassigned tasks, or check the sprint board of tasks not assigned to them in their domain of expertise and spend a ton of cycles of transferring ownership.

All other methods cause almost immediate attrition because they functionally create communication silos, duplication of information everywhere, and eventually just abandoning usage all together. If you don’t have a quarterback to sit on Asana all day, you might as well just manage your project in a simple slack channel. You can do all sorts of tricks like standard agile sprint boards, at mentioning, task duplication, which leads to even more confusion in an asynchronous FIFO, non PM, flat team. Assuming that developers are going to sit on asana scanning unassigned sprint boards, for that to work someone needs to religiously manage the board and prioritization vs easily indicating priority and awareness to underutilized employees through assignment.

I understand the potential tragedy of the commons with multi assigns, but you have the type 1 error wrong. It’s much easier to solve that problem with minimal effort through internal process, or managed by the engineering stakeholder, which would take far less time to manage than a single assign model. I spend most my time inventing


Actually, for those who run business with mutiple handoffs, creating copies of tasks only creates more work for managers. I am wondering if this is a design “flaw” rather than a feature. Otherwise, why would a Software company offer the features that customers are clearly asking for (as evidenced by the multiple threads on this topic). It is a desired feature. Either they suck at customer service, or cannot offer this because they cornered themselves by a design choice.

1 Like

There is a key concept of optionality that the Asana team is completely missing on this.

Because information always comes out later, in most instances it is best to wait until the last possible moment to make a decision, to maximize optionality. Of course some things need to be locked in… buying a flight ticket ensures you get a seat, but assuming there are no negative consequences, like if all airplanes had infinite seating available (and prices wouldn’t change), then you absolutely should not make a reservation until the last second required.

This is how business works. I have a team of 5 with overlapping skillsets. We have a task that needs to be completed by end of next month.

There is ZERO reason to assign this task to an individual right now. Someone may get sick, someone may take a vacation, the requirements may change, the project may falter and deadlines get pushed back, etc. Maintaining optionality, through the assignment of multiple individuals or a team is a huge value add.

If I look into items due soon, I want to see everything assigned to my team and follow up with whoever needs to be addressed. Once it becomes clear that someone has room on their plate for this, then it will be reassigned accordingly.

Have you Asana developers never had a family-style meal at a restaurant? Yes, eventually every piece of food winds up on someone’s plate and gets eaten by a single individual, but it’s not up to the waiter to assign who will eat how much spaghetti and who will get however many raviolis, that should be based on a pull model, and everyone able to be assigned to the task from the start.

To not even have this as an option is clearly costing you customers… we’re still in our trial phase and this will be a major point of contention.

@Brett_Mangel, I like your family-style meal analogy! Recently I wrote a reply on another thread that relates to the same question here. In case it may provide a workaround for you (not to negate the original request here), it is:


Hi @sean.farrington,

I’m wondering if you (and other readers of this topic) would find the solution I’m thinking about in this forum thread useful? While its primary purpose is not to handle multiple task assignees, it does work for that use case. In essence, it’s implementing a type of “creating copies of tasks”, but those would be managed by Flowsana so as not to entail more work for humans.

Hey folks - sorry if this was answered before but it’s hard to track 2 years of replies on the thread.

We have workflows for certain tasks that require more than one person to actively work on the same task for more than 15-20 days - daily. What sort of solution does Asana provide for that?

Within the current Asana, long story short, this is not possible. So you either create two tasks, OR you don’t assign it but assign subtasks for example OR you assign it to the team lead among the two.

Thanks for the reply Bastien!

I’ll try to find some posts and read more about how these ‘subtasks’ work. I’m curious though, why a feature request that has hundreds of replies across the span of 2 years isn’t considered as something that Asana might’ve gotten wrong and just change it?


Quick update - looks like the subtasks will work pretty great on our end actually but one thing is still unclear. Does one receive a notification when a subtask is assigned to him? Does that subtask (or the master task) show in his list of to-do’s?

Yes, they are regular tasks. The only shortcoming is that they are not part of their parent task project.

Couple of possible explanations for a situation like this:

  • this is against the vision
  • this is technically too complicated
  • that is required by a too-small number of users (compared to millions of users) and would create complexity for 99% of users while 1% want to use it
  • that creates technical debt and becomes quite expensive to maintain

I feel this would be a huge advantage and feature in Asana. I understand the need to have a single assignee for each task, but why not enable us to assign a Primary task owner and assign others to the task to be able to view its progress?

Further to my initial post here, I think this is seriously limiting the functionality of the software. For example Basecamp will enable you to assign multiple people to a task and even add a client rather than an individual.

This is especially helpful for those organization like myself who run a Digital Marketing firm and we have clients that we manage and talk with through the app in order to provide deliverables, assign tasks, and keep the project running smoothly.

The fact we here is “It’s not Asana Philosophy”. That’s the dumbest thing I’ve ever heard. All you paying customers don’t care how you use it or what your philosophy on it is. We paying for the features and functionality, you providing the service…

Maybe its time you rethink the ASANA PHILOSOPHY!!!


Yes, someone will receive the subtask in their “My Tasks” section if it is assigned.

I will use a subtask if I need multiple to review something, by putting their names as subtasks with dates and then myself as task owner to confirm everyone responded.

Add me to the ever-growing list of users who would appreciate having the ability to assign multiple users to a task.

Seems like another simple thing that should have been implemented right away, but somehow keeps getting ignored because of “our philosophy” or “difficult to implement because of (insert short-sighted decision)”.