What Asana is NOT (your organization may be using it incorrectly!)

Hey guys! I wanted to share some thoughts I had.

First of all, these thoughts are the direct result of a lot of organizational changes we’ve had in the last year. I hope this can be a didactic story and provide helpful knowledge for you as you continue working in your own organization.

lLet me get right to the point:

Asana is not primarily a database. That might sound obvious. You probably even agree. After all, you use this software for projects not for storing mass amounts of data, right? …Well, maybe.

Let me explain.

As our organization began to pick up major growth two years ago, we were still quite small so we didn’t have a functioning database or data-management platform. So what did we do? We threw all the “meta-data” relating to our clients into custom fields and the like, all inside Asana. In other words, we kept information like “Marketing Director”, “Client POC”, “Contract Start Date”, full lists of each client’s services, and the scope of each of those services, ALL in Asana. And believe me, much more information than just that.

In other words, we kept referential information that was important to our ongoing knowledge of each of our clients, all in Asana. Chances are, you’ve kept organizational or other datasets in Asana as well. The question is, where in Asana? In tasks. Do you see the irony? It is easy for some of us (as it certainly was for our organization) to hold referential, ongoing information that needs to be seen by multiple teams, in tasks. Well, what is a task? A task is by nature something that is actionable, something that is meant to be completed.

So we found ourselves often confused about our clients scope. Someone would walk up to me and ask “Which clients does x Marketing Director have?” or, “What’s the status of x client’s Google Ads campaign? Is it active?” or, “What’s x client’s Facebook Ads budget?”

Since all this data lived in Asana, we could find an answer–but the problem is that (1) it was growing increasingly difficult to find those objective answers since there were literally over 100,000 tasks tied to our domain, and (2) holding objective information in tasks creates the potential for data redundancy. What is recorded in one task may be recorded in another task by a different user, thus creating two conflicting “stories.”

I sent a survey to the team to prove my initial observations/validate my concerns. It was starting to become a nightmare. Based on my survey results, high percentages of people weren’t aware of the contractual obligations for our clients during their onboarding phase. Some of our Marketing Directors didn’t even know how to quickly identify all the services we were running for a particular client.

As a side note, I don’t want to give off the vibe that our organization is horrible, dishonest, or anything. In fact, we are an extremely integrity-based organization, and we were always able to work through the issues above, but it always took time and we always suffered much confusion.

Once I saw this trend starting, and once I realized that Asana is meant for actionable things (hence everything existing in “Tasks”), I determined that our organization needed a database, or a CDM (customer data management software). Over some months, I created a no-code relational database of all our clients’ data, and much of our organization’s internal data, and created a no-code frontend for it. Long story short, that platform is used to this day, everyday, by almost everyone in our organization.

Of course, tasks can and should contain important information, but only, primarily, information needed to get that task done.

Whereas our CDM is our single source of truth, Asana is our work management platform, where we execute on things. Whereas our CDM is our referential tool, Asana is our actionable tool.

Problem solved.


Thanks for posting your experiences, @Joel_Lee.

I don’t think it’s always a hard-and-fast rule that Asana shouldn’t be used for non-actionable things.

I think it may be dependent on scale and design.

I’ve seen many instances of highly successful lightweight “databases” in Asana. Even lightweight CRMs. And multi-homing and @mentions are both really great features that many find easy to use and offer some great functionality.

But I agree, it’s not a substitute for a full-fledged database. I just thought I’d write to mention that others may find value for database-like usages in Asana, depending on scale and with careful design.



I agree with Larry you can’t make such a statement as many companies (including us) successfully use Asana as a database for some use cases. And it works better than using yet another tool. But I get your point it might be confusing sometimes. And also not ideal in many cases.

I believe asana was at some point working on a new type of tasks to only hold information but we never heard anything back on the topic.

1 Like

Oh, of course it can be used for its CRM capabilities for certain people. I was making a bit of a dramatic overstatement, hopefully to connect with other organizations that find themselves in a situation like ours was.

I’m in total agreement with y’all though! Thanks for the thoughts.

1 Like

I am known for doing the same to get my point across :rofl: :heart: