We all love Asana, and the tool is growing really fast. They have an exciting roadmap, delivering often, but some features or use cases might be put aside for a while.
As an Asana user, champion or consultant, it becomes harder to follow those small “but”. For example, a portfolio can hold 500 projects BUT above 250 the Workload feature is disabled.
Let’s all work together and build a collaborative list of BUTs and for each one, let’s try to link to the existing forum post where we can all upvote.
Word of warning: it might be hard to tell apart a simply missing feature from a BUT. A BUT is something that did not follow an early feature release, an expected fast follow that is a bit slow to rollout, or things that never got implemented at all but make a feature feel partially implemented.
Great work, @Bastien_Siebman. I knew you could do a better job with this idea than I could!
To help convey the “BUTs” concept in case anyone is still wondering, my realization was that, as more and more features are added, GOTCHAs build up. They can be hard to keep track of (hence the value of this list) and they can even undermine workflows. For example, imagine you have a complex workflow and have a great solution in List view with subtasks for grouping and sub-subtasks for steps to carry out each subtask. Works beautifully with Sort = None because you can expand/collapse in main tasks view and easily navigate to see sub-subtask rows in the task detail pane. But if you rely on changing the sort, the workflow is no longer viable because of B5.5.
I didn’t get a clear sense for how to add to the list. I hope it was intended that I would add my BUT in this Reply.
“Having the calendar is good, and due dates are good, BUT the calendar should factor out weekends/holidays when a rule applies a due date (currently uses a duration of days that count Saturdays and Sundays and doesn’t account for holidays in that duration.”
@Bastien_Siebman, Your B3.1 links to a different product feedback request than the link I provided (which currently has 157 votes and isn’t in your list, I don’t believe).
You can set task due dates relative to project start or end dates on creation, but if you change those dates later, the task dates do not change (solved by Flowsana but still seems like a miss on implementation for Asana)
We use Jira and Asana, and I don’t think my team would use Asana without being able to identify the ticket for the task without a Ticket Number as they do in Jira. So we stick with Jira for daily tasks, which I keep the overview of the project in Asana, leading to an unintegrated system. If I could use Asana, it would like our waterfall plans to our daily scrums and I could just call out ticket numbers as shorthand during scrum.
I understand from reading others’ comments that there are numbers for each ticket, but it seems like they are long and/or hidden. I am a perpetual novice user without IT skills. If I ask for an add-on or have to pay for integration with another program, I will be questioned about paying for the add-on, or why I adopted a program that did not have what I needed in the first place. It would be ideal for us to have numbering for tasks as in a ticketing system.
In Jira, our tickets are created within each project so the ticket under our COVID project might be C19-148. Very easy to say to a colleague - “Hey, I sent you a ticket yesterday, deadline is today, can you take a look at C19-148.”
Thanks for your quick response - hope I explained it clearly enough.
Yes, I anticipate push-back if I ask for another program. But some department won’t adopt without ticket numbers, so I’ll have to wait until an opportune time to try to get Flowsana or Astogi. The reply seems to imply that Asana itself does not have plans to add ticket numbering to the feature set. Thanks for getting back to me and for providing resources to take the next step.
Asana does not communicate on their roadmap. My personal guess: they won’t, for 2 reasons: other 3rd party do it well, a tiny portion of users need it. (I don’t work for Asana)