I recently spent a lot of time in Asana. 

Webflow recently migrated its project planning to Airtable while maintaining its actual day-to-day project management in Asana. As the local Airtable expert I was pulled in to understand how the two systems can talk to each other (and whether this was a good idea). I had to dive deep into what Asana is and how it differentiates from Airtable. 

To my surprise, we ended up proposing a world in which both tools coexist peacefully and provide different value to different stakeholders: Airtable for project metadata and approval while Asana remains the day-to-day project management tool.

In this process, I came to my own deeply geeky opinion on what differentiates the two tools and when to use each. So here’s how I think of Asana vs Airtable.

Asana has strong opinions on how you should manage projects

Let’s talk about how Asana structures data (because we are nerds).

Asana operates on the basis of projects. Those projects contain tasks which can have sub tasks (which can have sub tasks etc.). Multiple projects can be grouped into a portfolio. 

You see what I’m getting at? This is a relational database! 

‍

The difference here is that this relational database has limited flexibility primarily when it comes to the type of metadata you can include at each level. Asana dictates the type of information projects, portfolios and tasks can have. 

Asana will always tell you the number of tasks completed in a project (or a portfolio) but there’s no way of getting the percentage of subtasks completed at the task level.

Asana projects have a start date, due date, owners and description. Do you need an extra date like an approval date or launch date that is different from the due date? You’ll have to add that date as a custom field which does not have the same support as a due or start date. So no filtering in views or calendars based on this date even though it’s no different from a due date from a conceptual standpoint! 

Do you want your projects to have a different status than on track, at risk, off track or on hold or complete? NOPE, that is now how we do things around here, says Asana!

In all of these cases, that’s simply not how Asana thinks you should manage projects. It’s not how it thinks you should structure relationships in a project management workflow or the metadata it thinks you should use. Coming from Airtable, this feels weird. I want power. 

The big upside is that Asana is easy to use. And if your stakeholders are not nerds like us, this way of structuring projects seems reasonable—probably good in fact. The value in Asana is that you click “create a project” and it handles most of it for you. Yeah you’ll get to a point where it might not be ideal but who deals in ideals anyway?

Airtable does.

It lets you create a setup that perfectly mirrors your ideal project management workflow—at a cost.

Airtable does not have opinions but you have to put in the elbow grease

Airtable does not have any opinion on how you should manage projects (or workflows generally). It simply thinks that relational databases are great for most business workflows (it’s right in this regard) and wants to give you as many of the tools of relational databases as possible. 

You can actually recreate the structure of how Asana thinks you should manage projects in Airtable relatively easily.

Airtable gets you around all of Asana’s limitations:

Want projects with more status options than Asana? Easy, create a table of projects with a status field with as many options as you’d like! You can even pick the colour (if you want light colours you’ll have to upgrade to teams for some odd reason).

Care about the percentage of sub tasks completed at the task level? Not quite easy but you can use a count field and a roll up field at the task level to calculate it and boom you have it.

The big drawback is that each step, Airtable is asking you: how do you want to manage this project management workflow? Answering this is quite hard! It’s not just one question, it’s so many questions. 

How many levels of subtasks do you want? 
What is the definition of each status option?
How do you assign people to projects? Is it by role or simply multi selecting users?
Do you want stakeholders to view this information in views? Or interfaces? What are all the different ways stakeholders want to look at this data?
- Airtable expert to unsuspecting project managers

Each one of these questions is difficult to answer because you’ve never had to make these decisions! Furthermore, each of these choices have consequences in Airtable: More levels of subtasks means more tables and more interfaces, multi selecting users means grouping by owner gets really weird. And every new thing your stakeholders need is something that needs to built! There is no “airtable can’t do that” whereas Asana won’t let you do many things!

So yes Airtable gives you the full power of relational databases to manage projects however you want. The cost of that flexibility is the elbow grease of setting it up correctly and maintaining that setup. It is not a one click setup like Airtable would want you to believe.

Where we settled

In the case of Webflow, we felt that we were lacking insights into what is upcoming in terms of projects and needed a way for approval before things end up in Asana. 

There is no way to get project approvals in Asana. So we created that workflow in Airtable. At a high level, projects begin in Airtable where metadata like owners, budget, objectives it relates to are laid out. By having all projects (requested, in progress, completed etc) in one place, it provides stakeholders the ability to see current and upcoming workload, budget and how projects roll up to objectives before approving a project. 

Once approved, day-to-day work for the project remains in Asana. To avoid project owners having to copy paste information between the two systems, I wrote a short script that creates a project with relevant information from Airtable and even pulls in an Asana template to reduce friction. 

This way of working isn’t perfect but we felt like it marries the value of both systems. Projects for us needed way more metadata than are available in Asana. And Asana is an easy way to get a project organized and started. 

So we built a system that used the superpowers that each tool provided. And in the process, I learned a lot about Asana (and frankly actually quite like it now) and wrote some awesome scripts. W’s all around.