I’ve never used Asana, but to me, that looks very similar to creating a filter on a view. From what I see, they’re using a series of filters to create favorites from tasks, which (guessing) are in a single collection of all tasks, not spread across 20 different collections. Airtable’s views are essentially favorites: make them once, and then come back to them any time you want.
@Kamille_Parks I appreciate the clarification, but @Jay_P tagged Jason, not me. Not sure if Jay discovered elsewhere that Jason is an Airtable employee, or if it was simply a Justin/Jason mix-up (I get that a lot). My guess is that it’s the former, and Jay would like to know from someone on the inside if something like this is on the development roadmap.
To that point, Jay, Airtable staff have never revealed their development plans publicly. The only time we get advance knowledge of upcoming features is when they choose to release a beta. Sometimes that’s a public beta, other times it’s private to a select few, but in either case the feature is far enough along that the team has decided to pull back the curtain and let folks take it for a spin if they choose. All other features in development are not revealed until release.
Returning to your earlier comment about how you feel this is “a basic requirement for users,” I respectfully disagree. In your subject line, you admitted that you were a new Airtable user, and you asked in your opening post how to make your setup more efficient. All of my experience is that spreading similar data across multiple tables is inefficient, and I believe that others who have commented in this thread would back that up. There are very rare cases where having identical setups in multiple tables is actually necessary (I ran into one about a week ago, but it’s the first one I’ve seen in the 18 months I’ve been using Airtable). More often than not, a user’s desire for similar data across multiple tables is a holdover from how other software is designed. When we clarify that Airtable is designed differently, and share the benefits of single-table design using views, most people see right away that a single table is far more efficient.
We’ve tried to come up with a way to make this work across your current multiple-table setup, but I think that the latest comment from @kuovonne makes it pretty clear that this is beyond “tricky.” Trying to bend Airtable to operate the way you want is a major technical challenge, with some limitations that literally can’t be overcome.
That takes me back to the single-table solution. If you need to make 50 views in that table, I don’t see how navigating those views would be much different than navigating 50 tables. You’re just scrolling through a vertical list on the side vs tabs at the top (and there are keyboard shortcuts to make that navigation even easier). More importantly, though, putting everything into a single table eliminates all of the technical hurdles we’ve been talking about.
If navigating 50 views still feels like it would be too cumbersome, here’s something to consider. Instead of making 50 views (one for each state), what if you had one view that you could easily switch between states? Most people think of manually modifying a view’s filter settings to change the records that it displays, but another option is to use a script. This view I’m talking about would only show records with certain data in a special field that this script would update. Run the script, pick a state, and the script updates all records to only show those from that state in that view. That keeps your view count low, and you still have the many, many benefits of having everything in a single table.
We’ve given you the best advice we know regarding efficient base design, and encouraged you to follow that design and learn how Airtable operates most efficiently. If you don’t want to follow that advice, then I’m not sure what else I can offer.
