Like I wrote in this task Notification for deleted tasks? - #3 by Riccardo_Mares I think ASANA needs some features to better manage the users rights.
By now all kind of users than can access to a task, may do everything: modify task, complete task, delete task, move task… It’s so much “freedom”, It’s really dangerous.
If you think ASANA like a professional project management tool, you may imagine how differents are the users roles: who writes the task, who can only comment, …
Please please please add something: at least a rule like “read & comment”, for users that can’t delete/modify/complete the tasks.
Thanks.
We’re always interested in the balance of flexibility and power, so I’d love to know more about when/where you’d like to “lock down” Asana. Is it most of your Projects and Tasks, or just a select few? What’s your experience been with our current model so far? We are in the research phase of user permissioning currently, and would love to hear more feedback
In the meantime, we’ve found that team leads are successful in our current model when they make conventions clear – often by creating a HOW TO reference Task at the top of the Project – and employing Private Projects and Teams when needed. Interested to know whether you’ve tried either of those strategies?
Hi Sara, usually we work in the same projects with different kind of
people: internal team (ex SEO), the customer, the customer’s web agency,
the customer’s copy writer agency,…
Please image a SEO Asana project: the SEO specialist create lot of tasks
about the site structure or the site contents.
It’s very dangerous if the web agency modify a SEO suggestion or sign as
complete a task, wothout the SEO (recheck). Or, worse still, if someone
deletes an important task by mistake or because he doesn’t like it.
Some days ago I posted via Twitter to Asana an example of workflow:
I hope I’ve explain better my needs.
I hope you implement as soon as possible a minimal user right management
system.
If you’ll like, in future, we may speak about project workflow.
I agree with this feedback above. I would also like the ability to limit who can add members to teams, so that people may not incorrectly add people to teams who should not be able to have access to all the projects thereafter.
Asana is very good at simplicity and user experience but totally fail in transparency. My team decided to UNSUBSCRIBE Asana because of these, and I think many teams and companies do the same. I believe in team collaboration and flexibility, however it bases on trustable and transparency system though. I suggest activity history logs and notifications make everything clear and accountable. What Asana doing now is keep everything in the shadow by let user edit and delete tasks, comments with nobody knows. Transparency or Opacity, Asana must choose. One more thing, market for enterprise is bigger and there’re enormous users waiting for Asana, I believe.
Thank you, all, for the feedback! We are currently evaluating what user permissions could look like in Asana, and appreciate hearing what’s working (and what’s not) in the current model.
I specifically need to have the custom fields only available to admins not team members. It is also complete madness that individuals can make changes and then delete the audit train that they did it.
@Chris_Wheal, we know from working with other teams and workflows that allowing team members to update fields like status is critical to their workflows, and limiting edit access would significantly impact their ability to contribute. So, I’m interested in the workflows you’ve set up that don’t work that way – where an admin should be the only individual that can change the CF value. Can you say more about that? What are the fields, and what has your experience been so far?
The experience is we just subscribed and are thinking of cancelling in less than 24 hours. Having no way of differentiating between team members is all very egalitarian. But for example, I want to allocate a task a price. I cannot have everybody else able to change that price. I also cannot have them change that price and then delete from the audit trail that they were the one who deleted made the price change.
@Chris_Wheal, thank you for the additional feedback. I understand your concern – as a source of truth, it’s important that as Asana Task reflect the actual state of the world.
I’m interested in whether you’ve had a team member perform the actions described – where they change the Task price and then delete the audit trail – or whether that’s a prediction of something they might do.
I ask because what we have seen work well for teams is an “Asana Conventions” document (or better, Project!) that lists out the expectations for use of Asana and might be able to address team members using Asana in a way that isn’t desirable for your workflow. More on Asana conventions here. Let me know what you think!
It’s the sort of thing I might expect to happen. This is not because I am working with cheats but because I am working with journalists. We are head-strong, know best, have no respect for authority (challenging and holding authority to account is in our DNA). If I say something is only worth a news story and somebody thinks it is worth a news analysis (longer and paid more) they might decide to change it, for the good of the project. I might find I am then over budget having spent more than I thought.
The main thing is that there is no point in having an audit trail if individuals can delete their activity.
@Riccardo_Mares, we are currently in the research phase of determining what user permissions could look like in Asana. We’re really interested in collecting feedback from folks using Asana now, so if you have any workflows that are being impacted or thoughts about how user permissions could improve your current usage, let us know!
Conventions are definitely important, but sometimes users need to be saved from themselves. I just uploaded 450 family photos to a Google Drive folder, and it didn’t occur to me to restrict other family members to “view only” since we’re all, well, family. It only took my mother about 10 minutes to accidentally delete all the photos while attempting to download them.
The point is that even if there are no bad actors, applications should only let users do things they’re supposed to do. For some teams, that means letting users do whatever they want. For others, it means something far more structured.
And so again rises the need for a public product roadmap… People giving feedback, Asana saying “we’re hearing you” but keeping quiet after that, keeping users in the dark.
@Riccardo_Mares, as posted a few weeks ago, we are currently (still!) in the research phase of user permissions. I appreciate the sense of urgency you feel as we go through the process needed to ensure that we’re shipping the highest quality product to our community. User permissions, in particular, would be a significant change to the product, with a myriad of downstream effects and decisions, and, as you mentioned, we have lots of feedback from our customers to consider
We are heading into Roadmap Week in late June, and should have a better sense of the schedule and priority of work across our product then. There are no beta features available currently, but @Alexis is an amazing internal advocate for getting community members involved in betas as they become available. Thank you, as always, for your commitment to making Asana a better product!
