🎯 Can a task in Asana be assigned to multiple assignees?

[Aline_Stapp]

Single Responsibility!

[Karen_Dixon]

I think if we are talking about sharing responsibilities on internal tasks, that can be correct. However, Asana is used by organizations that differ from an office/executive setting. Our company fixes espresso machines, coffee brewers and grinders for coffee shops of all kinds. When we send a Technician to a service call that requires 2 Technicians due to the scope of the work, we assign the first Technician and duplicate the appointment for the 2nd. They are together doing the work. We initially tried using Subtask for the 2nd Technician, but they did not notice that they were assigned to same task, resulting in few surprised Techs re: going to the appointments. Since duplicating, we have not had that issue. I think the single responsibility may not always work for service industry companies where more than 1 Tech is needed or if they are training a 2nd Tech.

[Gavin_Shields]

I think that for high volume, low value tasks it is appropriate and kinda standard to use a queue system and then assign a team as responsible for that queue. Whoever has capacity picks up the next task in the queue and on you go until the tasks are complete. For me, multi assignees makes sense in this instance.

Creating subtasks creates a legitimate pushback, typically from lower level staff, who complain they are now spending an inordinate amount of their day updating subtasks, getting confused in asana or being micro managed.

I love asana btw and agree on single assignees for high value, low volume tasks, just think that catering for this type of scenario would be useful.

[ka_nishiyama]

Regarding assigning multiple people to a task

• When two staff members should have joint responsibility
  The task with joint responsibility (50%, 50%) is the parent task, with no person in charge. Create two subtasks, and assign each to a different staff member. What about then?

• When maintenance work is performed by two people
  Isn’t there someone who instructs (assigns) the work to the two people and supervises them?
  That supervisor is in charge of the parent task, and the people in charge of each of the two subtasks are the actual workers. How about that?

---

P.S.

What do you think about having each staff member create their own “My Project”?

Assign multiple assignees on one task

It’s really painful to wait for this feature to be implemented, isn’t it? Instead, what do you think of my idea? Create a My Project for each staff member. Staff 1’s My Project, Staff 2’s My Project, Staff 3’s My Project, etc. Multi-home tasks that need to be assigned to multiple staff members to the “My Projects of the desired staff member.” In this case, set the task assignee to the project leader. Each staff member can process their own work by looking at their own My Project. I think it w…

[Rasmus_Jakobsen]

Given we have a flat organization we also have the need for multiple asignees. However, our workaround is to have a custom field with field type ‘people’ called ‘Relevant to/people involved’. We can then call up team members and add them so the task owners know how to add for meeting etc. This also has the benefit of being visible on the board tab.

[Erin_Shimamoto]

I wonder if there is a compromise that hasn’t been considered yet.

We all understand what an Assignee is. We also all understand what a Collaborator is. What if there was a third role distinction? Something along the lines of Accountable? (I’m sure there’s a better name for this.) We need more role clarity for tasks that don’t have tangible steps that require separate tasks.

My thoughts are that the Assignee is responsible for the Asana task itself—watching the comments, ensuring the tast gets marked complete. Those Accountable however, see this task in their My Task list, and get alerted on it. They know that they are accountable for the task in some form or another. They are involved in it directly. There’s not enough distinct steps that dictate they need subtasks or separate tasks. They are not just a collaborator meant to watch. It treats it as though they are the assignee, but they are not directly responsible for the Asana task itself.

One way I think our team could use this is with our tasks used to track our recurring meetings. I have a Weekly Huddle task used to track our time against. I wish those that attend this meeting are set as Accountable so this shows up on their list so they can easily reference and track time against it. The driver of the meeting should be the assignee. Any collaborators are just the informed parties. This is a simple task that doesn’t need subtasks or duplicate tasks.

I just think of how we assign roles at our agency with our clients. We always have the Driver, the Contributor(s), and the Informed. This is how I’m visualizing their relationship to a single task!

[Arthur_BEGOU]

Hi Erin

What if there was a third role distinction? Something along the lines of Accountable ? (I’m sure there’s a better name for this.) … Those Accountable however, see this task in their My Task list, and get alerted on it. They know that they are accountable for the task in some form or another. They are involved in it directly.

I think that you could easily achieve that with rules and projects.

• Create a people field called “Accountable” and add it to all your team’s projects (via the field library)

• Create a rule in all your key projects to add those
  

  

• Create a project called “Team accountabilities” and Group it by the field “Accountable” (the field should be in the project)

-Create saved views to recreate My Tasks views for each user (with filters and Group by).
For example, Group by due date to create a similar view as My Tasks.

Please let me know if that could make sense

[Scott_Costin]

I totally get and respect the thinking behind the “single assignee” approach — having one person clearly responsible makes sense in a lot of scenarios. But to be honest, it doesn’t always reflect how work actually happens, especially in fast-moving or highly collaborative teams.

Just because Asana has chosen that model doesn’t necessarily mean it fits every workflow. A lot of other MRM tools allow multiple assignees, and they do it well. It’s not about avoiding accountability…it’s about enabling flexibility for situations like:

• Brainstorming or concepting tasks

• Event production and coordination

• Reviews where multiple people need to weigh in simultaneously

Breaking those into separate tasks just to meet the “one owner” model can actually make things messier and harder to manage. In some cases, assigning multiple people (ideally with custom or split time allocation) would improve visibility and workload clarity, not hurt it.

Even just having the option for multiple assignees (with guidance or best practices built in) would go a long way. Right now, the stance of “we don’t support it because we don’t like it” feels a bit limiting. And honestly, as teams grow, that rigidity can be a blocker and even push companies to explore other tools that give them more flexibility.

That said, I’m not just here to complain — I’d actually love to chat more about what’s worked really well for my teams in the past. I think there are some real opportunities to evolve Asana’s functionality without sacrificing the things that make it great today.

Happy to share ideas anytime!

[Bastien_Siebman]

@Scott_Costin

Even just having the option for multiple assignees (with guidance or best practices built in) would go a long way. Right now, the stance of “we don’t support it because we don’t like it” feels a bit limiting.

I don’t work for Asana, but my own pov is “We don’t support it because we know people will use it badly in most cases”. And also, I believe this post well describes the discussion here Death by a Thousand Buttons — from the Desk of van Schneider — Edition №268. Allowing it means having “another” option, a different way to use the app, and makes it harder overall

[Scott_Costin]

@Bastien_Siebman

I don’t work for Asana, but my own pov is “We don’t support it because we know people will use it badly in most cases”. And also, I believe this post well describes the discussion here Death by a Thousand Buttons — from the Desk of van Schneider — Edition №268. Allowing it means having “another” option, a different way to use the app, and makes it harder overall

The Van Schneider piece makes a solid point (great read by the way) feature creep can kill clarity. And yes, it’s smart to question every new request or idea. But when it comes to MRM systems, especially in fast-moving or scaling teams, a strict “less is more” mindset isn’t always practical or helpful.

Some Thoughts:

• Teams operate differently

  • What works for a small startup, a product team, or a global in-house agency can vary wildly. A rigid MRM system that assumes one “right” way of working risks becoming irrelevant the moment it doesn’t match reality.

• Flexibility leads to adoption

  • If the system can’t adapt to how people actually work, they’ll find workarounds. That’s when things get messy, not when you give teams room to shape their own workflows.

• Best practices should be a starting point , not a constraint.

  • Structure is important, but it should be flexible enough to support different ways of working. A good MRM should guide, not dictate.

• Iteration isn’t feature creep.

  • Schneider warns about complexity, and that’s fair. But not every new process or tweak is clutter, sometimes it’s exactly what’s needed to solve a real problem. The key is being intentional, not inflexible.

• A system should evolve with the team.

  • Whether you’re scaling, shifting priorities, or just learning what works, the tools you use should support that growth, not lock you into a framework that stops being useful.

  The goal isn’t to avoid change, It’s to manage it well. A strong MRM gives teams the space to build what works for them, while using best practices as a compass, not a cage.