We got this question from a participant in our training today, and I wanted to share here for others who have questions about notifications within projects and tasks.
Question: “If a project is public to a group of people, do you have to add every person as a collaborator on each and every task as well?”
Answer: "It depends what you want them to be notified about.
Project members will get updates when new tasks are added to the project and when new progress updates or conversations are posted.
Task collaborators will get updates when changes are made to that particular task (task gets completed, comment posted, etc.).
So, if you want folks to get updates about changes made to every task in a project, you would need to add them as collaborators to the tasks. You can do this in bulk by multi-selecting (clicking the first, holding shift and clicking the last) and then adding the collaborators to all of them."
Does anyone else have guidelines on who they add as a task collaborator vs. project member?
7 Likes
Hi,
we handled it usually like this in my companies:
Project Collaborator:
People who were involved in the project with more than a single tasks or a particular interest. Note that every project member can adjust what he wants to get notified about. Some people prefer to get an inbox notification every time, others prefer to check the overall project once a day.
Who you add also depends on the culture in the company! I worked in startups with a high level of trust, where people did not want to get notified about everything another department was doing, however, I also worked in big corporations, with a lot of politics, there if multiple departments were involved in a project, it was much better to add all somehow involved people to the project, even though they were probably not reading it, BUT they could not blame you later for not informing them 
I know from project management perspective this is not the best way to do it, but sometimes it is necessary to protect you from not so nice colleagues.
Task Collaborator:
People who contribute to the task. PLUS a manager if he is specifically interested in the task. For instance, you are in a meeting about a particular project, if the responsible manager, who is not really involved in the project, has a suggestion for a task or he is particularly interested in a specific crucial task/milestone, we add him to this task. He does not need to be informed about every single task in the project, just about this important one.
Other benefit: Very often, managers make suggestions and the team members forget about it, because too much work. Days later, the manager asks about it… Bad situation. If you Create a task for the manager’s idea and add him as a collaborator you show him that you appreciate the idea, and even if it is not actionable right now, it is not getting forgotten 
Any feedback on this? Do you do it in a different way?
Best,
Sebastian
3 Likes
The most important use of task collaborators for us is to notify someone that a task has been completed so they can start working on another task. This is what dependencies (“Mark as Waiting On”) are supposed to be for, but that feature is very cumbersome to setup and not quite mature in execution. When the dependency is obvious (as is the case for our content calendar workflow), using task collaborators is much faster to setup.
1 Like
@Kaitie, the difference in notifications between Project members and Task collaborators has caused confusion from time to time for people at our company. The way it has been set up makes sense but it’s not intuitive. Leading to a gap between how people think Asana is going to behave and how Asana actually behaves.
People are surprised and re-surprised that they aren’t automatically collaborators of Tasks in a Project they are a member of. And they end up feeling like they are missing out on Task updates they should have been aware of.
I’ve had to remind people a number of times that they have to look for the notifications about new Tasks in a Project and add themselves as a collaborator as they see fit. They believe having the software automatically do that for them, would make for a better application. I agree, as long as this was an option, that allowed users to decide per Project if they want to automatically become collaborators of a new Task or not.
10 Likes
Thanks so much for the thoughtful feedback, @Vince_Mustachio. I understand your team members’ thoughts on this, and I appreciate how you detailed out the workaround you’ve recommended and the frustration they are feeling with the current process.
I’ve documented this for the team that focuses on project functionality improvements, and we’ll keep you updated as we are able to work on this down the road.
1 Like
Thank you @Kaitie for considering my feedback and bringing it up for attention internally.
And thank you for offering updates in the future. Updates are always appreciated.
For what it’s worth Craig I have had this same issue (the “mark as waiting for” problem) and I emailed asana about. This was their response:
This is definitely an issue here. I think part of this is that there are some other components under the hood which this depends on which we are currently still working on.
As for an extension of this workaround, the only thing I can think of is if you create a template for all of these projects and set it so the dependencies copy ahead of time. This way you won’t need to manually set dependencies and run the chance of missing the dependency not showing up in the typeahead. If dependencies vary on each project, however, then I do see this not being ideal.
Apologies again for the hassle. If you have any questions, or if there is anything else I can help you with, please let me know.
So, I started making templates for all of the content we create (each piece is it’s own project). It’s working just about perfectly - it’s really easy to do all of the mapping (and only do it once). The only issue now is people are assigned to template tasks w/ no due date.
1 Like
@Kaitie - I am the owner and admin of our company so it’s really hard for me to see what others can and cannot see and I keep getting really confused about collaborators vs. members. This is our workflow –
Project A- (members of project: me and coworker 1)
Within project A there are 5 headings (research, script, production, internal screening, publish content). It’s only necessary for me and coworker 1 to see all of the work being done in all of the sections. We assign tasks to both additional co-workers and external independent contractors (guest). However, there are various steps throughout the workflow were I need to get feedback from coworker’s 2,3,4,5 and 6 and we need everyone to see each other’s feedback. I am assuming if coworker’s 2,3,4,5 and 6 are following the task (which I might call “Gather input from Notes on draft 2 of script”) and coworker 1 who is a member of the project, will all see when I ask for their input if I drop the request in the comments of the task, even though the task is assigned to me. Is that correct?
I am trying to avoid creating sub-tasks for coworkers 1 - 6 in my main task of “Gather input from Notes on draft 2 of script”.
Does this make sense?
Thanks, @Melissa_Panzer. We do use templates extensively, but there’s a catch. Our content calendar has templates for different types of content, for example a news release. Our general news release template has 21 subtasks, some of which are dependent on others. We’ve used this template over 100 times already, which means there are 100 subtasks with the same names.
When we try to make a new dependency, either in the original template, a new similar template, or any individual instance of a template, we can no longer use “Mark Waiting On…” because the typeahead only shows 10 results and the one we want isn’t there. If the subtask name is too long, the task name is also obscured.
The typeahead should always show matches in the current task first, and it should always show the task name for each match. But it doesn’t.
The workaround is to rename the parent task, create the dependency, and then put back the original name.
Or just use collaborators instead of dependencies. As far as I can tell, the only difference between the two is that the notification for a dependent task points out that the parent task was completed so you can do the dependent task, whereas the collaborator notification only says the parent task was completed. But for our templates, it’s pretty obvious what the dependent task is.
1 Like
Copy URLS. This is a huge time saver when you have a million templates and dependancies. Starting with [task a]. Go to the [task] that you want [task a] to be dependant on…copy the url, and then go back to [task a] and paste the url in the dependancy. Easy!