It would be great if there was a visual indicator to show that another team owns a project, so as to avoid the confusion when someone thinks that project should not be ‘in’ that team and deletes an entire project because they already think it lives elsewhere.
One scenario when this is likely to happen is when duplicating projects, putting the duplicated project in the new team with the new name, and then somehow seeing that project in the old team still (and then deleting it! - fortunately it was a fresh duplicate and could be easily replicated).
The following visual Indicators could exist:
- In the nav bar team list dropdown, a little shortcut icon (doesn’t need to show here which other team it lives in, just that this is a shortcut/link to that project).
- In the Team’s Projects list, a visual indicator (shortcut icon) plus the name of the team that owns the project. This would make VERY clear that this is the same project being seen in another place.
If security/privacy is an issue (i.e. not wanting to expose the Team name), the user could still see the shortcut icon without seeing the team name, or see ‘Private Team’ if they are not a member or guest of that team already.
I think the main issue is that the concept of “team owning a project” doesn’t really exist, or at least is slowly going away. A project technically lives in a team, but that’s getting harder and harder to see. Instead, we can now have multiple teams as project members…
The current implementation seems to still be that a project is homed in a team, and yes, multiple teams can be members of that project.
That latter part is great, but what is being pointed out is that it is causing confusion because there’s isn’t the visibility of uniquely identifying a project. Yes, it is a similar (and positive) concept to a subtask that can be seen both as subtask in a task AND added directly to a project. Or of a task that is homed in two projects. I.e. the same task in multiple places. Except, for tasks, it is quite clear (from breadcrumbs and/or the Project(s) field) that this is the same task.
The issue I am bringing up here is that with Projects right now there isn’t the visual indicator of where that project is, meaning it is harder to distinguish if these are different (duplicate) Projects with the same name vs. the same Project visible in more than one place.
In more detail, my experience (which I only understood after finding Richard’s explanation, along with a note that other customers have been confused by this, in 💡 5 tips and notes on the recent changes to sharing projects with teams) was:
- Duplicating a project, at the same time changing the name (let’s say from ‘2024 Registration’ to ‘2025 Registration’), and putting it in the new team, but the project duplication settings were such that the current team stayed as members.
- Later back in the original team’s project list, then seeing this new project ‘2025 Registration’ there, as well as knowing it is visible from the new team’s list. There’s nothing indicating they are the same project and so I reasonably think I must have duplicated the project twice by accident, with one of those times having forgotten to update the team.
- So then deleting ‘2025 Registration’ from the original team’s project list, thinking a copy of what I want is safely in the new team. And then discovering it is also gone from the new team’s list too.
- Multiple this issue by having done this at the same time for a few projects: ‘2025 Accounting,’ ‘2025 Prep and Setup,’ etc, and it is at best a brain scratching issue during team/project setup, and at worst, had we actually begun to work in those new projects, actually a problem with loss of data.
Now, having read through Richard’s 5 tips and notes, I understand what is going on behind the scenes and can watch out for co-workers who won’t have read this but may fall into the same trap. I can add a note to a project about it being ‘multi-homed’ in teams (because the way things are laid out now for sure makes it still looks like projects live ‘in’ a team) so co-workers don’t see other projects that are carried forward rather than being duplicated (e.g. libraries) still visible in old teams and think they are copies that shouldn’t be there. But the possibility for this confusion would be greatly reduced if it was just clearer, somehow, that a project has it’s ‘home’ in a certain place.
1 Like
Hi @Sarah_L , I’m glad you found my post useful to understand what is technically going on behind the scenes. However, I agree with @Bastien_Siebman that Asana are moving towards the idea that Teams are simply a group of people that you can easily ‘tag’ to share projects/portfolios with.
Therefore, a visual indicator may not be necessary in the near future, unless Asana introduces a ‘Responsible team’ for a project, just like a Goal has a responsible team. I wouldn’t be surprised if they did this, as a reason to still populate the value for the native ‘Team’ field within a Portfolio.
@Richard_Sather Thanks for the additional feedback. I guess the real ask is something to indicate the uniqueness of a project without it having to be a completely unique project name. It doesn’t fit with Asana to expose a kind of id, so a Team seems like the natural request.
To be fair to my request, right now Asana DOES show the Team name when you try to add a project to a task either in the Details View, and also when multi-selecting tasks and adding a project, and in the Search. It would fit with the current implementation to show the same Team name particularly when a project is visible in a Team’s project list but that’s not the same Team.
Team names on the left in grey, when adding a project in Details view:
The same from the black toolbar in multiselect:
The same in the search results:
No indication in a Team’s project list - note this is REGISTRATION TEAM 2024, and all the indicators in the other places in Asana I’ve shown above are that this project is homed in REGISTRATION TEAM 2025. In this scenario, we are carrying forward our Training and FAQ projects from year to year, but want to keep them visible to last year’s team members - exactly a use case for having multiple teams have access to these projects:
As a note, we are on the Starter package, so do not have access to Goals or Portfolios. I’d hope that the same consideration of clarity would be given for users at whatever level of Asana package they have, even if they don’t have these other features that make use of a “responsible team” field.
