Reference numbers for tasks


Awesome creativity!

Asana, strange that someone has to jump through that many hoops to get a feature that seems foundational.



I find that the best way to review a bunch of task in a meeting is to create a project about that meeting. You link in all the tasks you want to discuss ahead of time and put them in a section called Agenda.

Before the meeting, you invite your team members and they can link in any tasks they would like to discuss. You can leave conversations, etc., just like any project.

Throughout the meeting, if any new tasks are created, you can add them to a section called Action Items.

Before the meeting is over, you can make sure that all tasks are assigned to someone so they don’t fall through the cracks.

After the meeting is over, you can go through those tasks and put them in the relevant projects, assign custom field values, etc.

This is an old thread, so hopefully you got something figured out, but your use case example seemed perfect for a Meeting project.

Another way to do this would be to create a “Meeting” tag. You could then go through all the tasks you want to discuss in your meeting and tag them. Then, when the meeting starts, everyone can run a report on the tag “Meeting” and they will have the exact list of tasks to discuss.

I think each use case depends on the scope of the meeting.


I think the main issue here is that people are thinking about Asana all wrong. They are bringing ideas with them from old paradigms. I’m not saying they are wrong, I’m just saying this different direction that Asana has chosen has caused frustration. But there are different ways of thinking when using Asana that can get you what you want if you step back and look at the problem you are really trying to solve.

In Erik_Graham’s case it was reviewing tasks in a meeting. Creating a meeting project and linking in the tasks to discuss is a very easy and well-supported way to discuss a subset of tasks. That’s one of the main reasons I love Asana (linking a task to more than one project).

Neil_Kessler’s example is a bit different. But sometimes Asana just isn’t the right tool for the job.

I’m not sure why some here chose Asana as a help desk software when there are a lot of other options that have unique IDs, but in my case, I wanted the entire company to be able to use one tool and I felt like Asana was more generic and easier to use in other departments of the company. But to do that, I understood I was giving up some things (that really weren’t that important day-to-day).

As a developer myself, I don’t want to expose my unique IDs to customers because it locks me into whatever system was generating those IDs (often it’s a database). If I want to change it later, I can’t without breaking a million external integrations that my customers created on their own. Imagine how upset you’d be if you spent a bunch of time building a system based off the Asana unique ID and then they changed it. (I would guess that’s one driving force in not making the change.)