I’m going to bring up a question already asked two year ago and that I feel could be a great feature: restrict task visibility in a project.
I am trying to create a project that would centralize the different Need review / Approval tasks for our small team.
The idea would be to create the task in there, assign the person we need the approval from, the task is added to their My Tasks and then automatically added to a personal dashboard in a specific section (using "if tasks is in project Approval / Review, then move the task to…) .
However, there may be some of these tasks (or part of the information in those tasks) that need to remain confidential. Allowing restricting the view of the tasks to those we create and the ones we are assigned to only, would allow us to centralize all of these tasks in a same project (the base of the rule for each person) since we’d like the whole team to have access to it.
Is there any thought since 2024 about creating such as feature?
Another example is the whole team may be working on a same project but part of it needs to be confidential and should only be seen by the leadership team.
Thanks for raising this. If someone has access to a project, they can access the tasks in that project, so Asana doesn’t currently support hiding individual tasks inside one shared project.
For your use case, the cleanest workaround is to keep confidential work in a separate project that’s private to the right members. You can also create a rule for this (create a single-select custom field “Private” → When a task CF is changed to Private, move the task to a leadership-visible project) and keep only non-confidential approval tasks in the shared project.
If the sensitive part is just a field rather than the whole task, private custom fields may also help on Enterprise plans.
Since this sounds like a feature gap rather than a setting that can be turned on, it may be worth posting it in Product Feedback as well so others can upvote it.
Thank you, I added it to the product feedback section.
We want to minimize the number of projects, especially with the fact that some of our team members are just starting to use Asana and can feel a little overwhelmed at times.
I might just help them set up rules in their personal dashboard and My Tasks, sothat if a task name contains [Review] for example, then it needs to move to Review section of the assignee’s personal dashboard.
Hi @Virginie6
If manual tagging ever becomes prone to human error or difficult to maintain as work scales, another robust approach is implementing a “Mirroring” model via the Asana API.
Under this architecture, the main project remains completely private to the leadership and review team. A lightweight webhook integration listens for task updates: whenever a task is marked with a specific status or designated as “Public,” the system automatically clones only the non-sensitive metadata (such as the task title and due date) into a shared team project.
I’ll be honest and say I’m not sure I understand this…
I have actually found a workaround I believe. If every team member has a “Personal Dashboard” (even if it is a private project), they can each have a Review section and have [review] in the name of the task. When A creates a [review] task assigned to B, B has a rule in My Tasks that automatically adds the new [review] task to their Personal Dashboard - section Review.
It looks it does not give B access to A’s Personal Dashboard and the task remain between A and B, without anybody else seeing it.
Might not need to have a full project for this. I’ll take the idea to my colleagues and see what they think. It would just take a few minutes to create the rule for each of them.
The only thing is because we do not have access to the Approval task type, I need a way to clearly notify A when B has approved or reviewed whatever was in that [review] task without it just disappearing because B checked it as completed in their Dashboard.
1. Broken Audit Trails & Hard-to-Find History (Major Issue)
Because there is no centralized “Completed Reviews” project, completed tasks are scattered across everyone’s private Personal Dashboards.
The Breakdown: If someone needs to look up a decision, file attachment, or feedback comment from a review completed three months ago, they won’t be able to find it easily.
The Impact: Since the tasks live inside individual private projects (the Personal Dashboards), other team members cannot search for or access those completed tasks. The company’s historical knowledge is locked behind private user silos.
2. Human Error & Broken Automation (Minor Issue)
The entire workflow relies on spelling consistency.
The Breakdown: If Person A makes a typo and titles a task [reivew] or simply forgets to write the tag, the rule will not trigger.
The Impact: The task will sit in B’s standard inbox without being routed to their dashboard, causing missed deadlines and broken communication.
A Healthier, Zero-Code Alternative
To prevent these major issues without forcing them to use complex APIs, they should use a Centralized “Completed Reviews” Project combined with a native Asana Rule:
Create a Private “Review Archive” Project: Make a project that is restricted only to the necessary team members.
Automate the Hand-Off: Set up a rule on the team’s templates:
Trigger:Task is completed
Action:Move task to the “Review Archive” project and Reassign to the Creator (Person A).
The Result: This keeps active work private during the draft phase, notifies the creator the moment it is finished, and automatically builds a searchable, central history of all past approvals.
What do you think, this may vary depending on the customisation there might already be but would you agree with this ? Thoughts ? thanks
Thank you for your input and feedback. It would be an interesting question to ask the team: do you need to be able to look for those again, especially if you were not involved in the first place?
It is very hard to know who needs access to what. As a small team, we all work together and may need something to be reviewed by B and the next day by C. But who would need to potentially go back and look at those again in the future? Only the parties involved? If so, then can just check their “completed task” in that Review section. Or them + leadership? That’s where we run into another issue.
If we have an Archive for past reviewed, would that be visible only by leadership so that confidential things that were reviewed remain confidential? Otherwise we go back to having the same issue as the project I wanted to create in the first place.