I would love this feature!!!
I second everyone’s request for this feature. It is available in your standard Excel spreadsheet files, so I am surprised isn’t already available in Airtable. That being said, you guys are doing an awesome job and I love all of the features Airtable has that Excel doesn’t have (or Google Sheets for that matter). Keep up the good work!
Would be very nice to have…
This is a feature that would tremendously improve AirTable’s utility for our nonprofit organization. In our ideal world, we would have a Contacts base with names that could then be linked back to from other bases such as Events, Projects, Donations, Grants, etc.
Clearly, this is a very popular feature request! As Andrew said above, it’s certainly something that we are thinking about, though there are a variety of technical hurdles that would need to be cleared first. Since this is a huge undertaking, we want to make sure that we approach this in the correct way. Any specific ideas on how and why you’d want linked bases to work would be greatly appreciated!
Based on your responses, it seems like there are at least few reasons why one might want to link across bases, all of which raise interesting questions that we need to consider going forward:
Linking across bases could work as a form of granular permissioning (e.g. the Sales team has access to the sales base, and the PR team has access to the PR base, and though they might be able to see selected data from the other team’s base, they wouldn’t necessarily be able to alter it or read all of it). If this is your main reason for wanting cross-base linking: would your needs be met by Airtable implementing more granular permissioning controls at the table level or even the field level (e.g., password protected/hidden/redacted tables/fields that certain users are not allowed to see)? Is it more important to you that different users have access to different bases for privacy reasons (i.e. it’s mission critical that certain users don’t see certain bits of information), or for convenience reasons (i.e. I don’t want all users to see everything in one big base because not all of that data is relevant to their interests)?
Using linking across bases in order to create a manager/“master” base, which draws information from a number of sub-bases. Would your needs be met in this case by some sort of reporting functionality that takes information from many bases, or is it particularly important that this information takes the form of another base?
(Please correct me if I’m wrong about this.) A general sense that a large base with many tables feels cramped—that you have to “cram” what feels like too much data into one place. If this describes you, can you articulate why you feel this way? Is it because of how a base with many tables looks? Is it because of loading times? Is it because you feel like having too much information in one place is overwhelming?
Other considerations: How would you like linking across bases to interact with permissions? Say there are two bases, A and B. A user has access to Base A but not access to Base B, and Base A includes links to Base B. What should the user see when they look at Base A? How would linking across bases work with editing? Should you be able to edit the contents of Base B while in Base A, or should you have to go to Base B first?
There are so many things to say about linking bases, but this is enough for now, I think.
Total Newb here…
In addition to technical hurdles, this would affect the revenue model. If I can split my row count amongst multiple bases and still have them do things together then I can get around the 1200 row limit easily… Wouldn’t be hard to fix.
To answer the previous questioner:
Not important for my work (small catering company), we’re pretty transparent. just kidding, this is important!! See example below about employee directory as a subset of the “HR + Scheduling + Hiring Base”
Reports! That seems really cool. I could see someone making a hacked together Quickbooks. And I don’t see a use case for our organization… yet. However, if we were tracking which employees were at which events and where we got the best feedback and then some third variable related to the hiring process??? Seems complicated
This feels true for me/intuitively sensing this about other posters Compared to GoogleSheets the stacking of tables makes it easier to see where they are.
Here are some ideas for improving the cramping
Design Templates as Modular Tables or Sets of Tables that can be added to a base instead of setting up a whole new Base. The current template system encourages a proliferation of bases whereas that is not the correct design path to be taken from a DB architecture (or revenue maximizing) standpoint in my limited observation
Alongside the permission/granularity tool there could be a “table of contents” or some other kind of “tutorial” overlay that might allow for someone who only needs to see a part of the base to have a streamlined/guided interaction with the parts that matter. This could be a link that allows the recipient to have a particular view or “portal” into the base, basically like the embedded view but with more power.
For example: We track applicants and existing employees in the applicant base, since we hire some people only a few times and others full time and that changes year to year we want all their info there… we’re now getting ready to use that info to schedule folks for specific job roles (pizza maker, server, driver) and want to optimize for everything from days off to skillset to training and loyalty/seniority. If I had a way to just show the “company directory” part of that base I would love to share it with everyone. Another “view” or “portal” would allow employees with certain skills to schedule themselves for the shifts they want with some parameters
I have barely started using this tool and I LOVE IT! Now I just want to get our catering event management system to integrate with your tools!) info.gatherhere.com/platform
I see some community benefits like reduced tables redundancy and by the way, cloud space saving.
+1 me too. this would help us a lot.
As for 1, we would totally benefit from having granular permissions, for both fields and tables. There’s information that once it enters the base it should not be changed, and I’m in constant panic that if anybody makes a simple error (like pasting to a cell too many), we could end up in big trouble. I also would like to link records to another table that some users should not be able to access.
Regarding 2, we do need something like that but haven’t thought about it too seriously because we know that Airtable doesn’t currently allow us to do that. A reporting functionality that draws from many bases could, however, do part of the trick, but not sure what you’d be thinking about. The part ithat reporting wouldn’t cover is that we’d need the main base to be able to edit info in the sub-bases.
Re: number 3. Nahhh For me not a sufficiently strong reason to bug you to implement linking bases.
re: @Mics_Sky comment – We have ended up with a lot of duplicate data because of the need to separate information due to a conflict with permissions. We’d be saving space by linking tables.
I have ideas about your final comment/question @Katherine_Duh , so if you want me to share our thoughts about that, let me know where it would be best to do so. Thanks!
Yep. This would be awesome. Although I realize that this is a work around sub upgrades. Think about it, there is a limit for each base. If this feature was granted, then more people would be creating bases so that storage in each base would decrease. That’s just unfair to the company. You might as well pay for it. It’s a good product anyways. Go support them. lol
Hum… really ???
Sorry for the delay… OK, i understand your point of view. I see things positively and appreciate that i can have some space for free so that i can try the product or even recommend the free plan to small non profit organizations.
@Mics_Sky Just trying to be realistic here. It just how it works. Maybe I should have said it in a more positive tone so that it wouldn’t offend you so much? lol
Okay, I edited it. Better?
For us, linking bases would be a matter of workflow and permissions restrictions.
For example, I want the guy in the field to be able to perform an audit or inspection, being able to link the client information, location info, etc, into the inspection fields. But I don’t want him to have access to their contact information, or any other data about them stored in the client table, since I don’t want anything accidentally edited or financials seen.
Secondly, as a matter of easy workflow, it would make more sense for us to do a base for CRM needs… client proposals, their contact information, notes about winning the proposal, how much we are charging them for services, etc. Then I can have my secondary base for the raw data… the equipment we are servicing, where it’s located, technical information, etc… where I can schedule inspections for the equipment included in the client proposals we won. In that way, once a proposal is marked as “won” in the CRM, I can use the same stored data to open a project up in the second base.
This would cut down on the sheer amount of information I’m looking at all at once. Right now I use a different program (just found you guys and I’m loving it so far!) and I have to keep all my tables in the same “book” since there is no way to reference data across books. The amount of data is just confusing to look at. I get lost easily and it’s occurred to me more than once how much easier it would be if I could separate out different aspects of the business/model/flow to accommodate. When I’m working on equipment maintenance proposals, I don’t necessarily need to see every inspection a piece of equipment has ever had, but since it’s all in the same book, I see every detail of everything I have linked. I just need to see the equipment that belongs to the customer on this particular proposal. Even if I hide that detailed part of the view, it still slows down my load time considerably. It would be nice if inspections were housed in another base, so I could reference back to the equipment> it’s owner> our signed agreement without having to cram it all in one.
I still love this software, but this integration would make it unlike anything else on the market in this affordable price range.
Thanks for listening!
@Katherine_Duh Our use case is a bit different from those you’ve described. We are a small team using AirTable mostly to manage marketing tasks related to our products. Each product has a base with tables for projects related to the product. In addition we have a separate base for all marketing materials (videos, brochures, etc). This is separate from the products because many of these materials apply to more than one product. Right now there is no way to tie that back to the products and include those materials in a project.
In addition, every one of our bases currently contains a “Task Owner” table. I would prefer to have one “Task Owner” base, and all other bases could reference that. In addition, as a task owner, I could go to the “Task Owner” base for a compiled list of my tasks from all the bases.
I think both of these scenarios would fall into that “master base” category, but I wanted to provide some additional context on our use case just to clarify the functionality that we need. It just so happens that our products are software products, so I appreciate what it will take to implement this kind of new feature. If you need more detail to develop the user stories for this feature set, feel free to reach out.
Our team absolutely loves AirTable, so keep up the good work!
Definitely #1. I am a landlord who shares information about tenants on a need-to-know basis with vendors. By restricting what they can see more granularly, your product would be much more useful. Now I can share basic contact info and such, which is useful. However, I cannot have a person who needs to edit a table to update a job order or upload pictures and not provide access to the entire base as I understand it. Not useful for any kind of cross-organizational boundary scenario. I was trying to link bases and realized that was impossible. I was glad to see this request for more granular control of the pieces of the base, which would be a very meaningful addition for companies like mine.
Airtable Powers That Be,
Before you solves this problem by enabling base-linking, I’d love to see a solution that’s similar ton"views".
Linking bases sounds powerful, but I worry the product would lose it’s simplicity. The more complex Airtable is the less I can get team members to participate.
Hashim, I wouldn’t worry about that. The way I see it, the ability to link bases would be a very powerful feature, but at the simplest level, linking bases could be similar to linking tables within a base … really more of a lookup function.
Then there are the more complex use cases, like rolling up data from multiple bases to populate a centralized base or the reverse, parsing data from a centralized base to populate other bases. That would be very powerful but much more complicated.
For now, I would be very happy to have the most basic link between bases.
But even if they eventually implement some of the more complex features, that doesn’t mean you have to use them. You could keep your bases as simple as they are today while the rest of us drive ourselves crazy linking bases.
Think of it like an Excel spreadsheet … Most of mine do basic calculations from data all on the same sheet. Sometimes I’ll get a bit more complicated and do calculations from data across sheets in the same workbook. And occasionally, I’ll go completely mad with pivot tables and data from external sources.
But the fact that those complicated options are available doesn’t have any impact on my simple spreadsheets. Those are still simple. And so far, I’ve had the same experience with Airtable. Some of my bases are like that simple Excel workbook with a few sheets that really amount to a collection of lists, while others have lots of tabs, calculations, and links between tabs.
Whatever features they add, you can always choose to keep it simple.
@Keri_Sprinkle I politely and wholeheartedly disagree.
Typically the more flexible and feature rich an application is, the more complicated it is to use it, and the harder it is to get everyone in my org to adopt it (or standardize how everyone uses it)
And adoption is more important than powerful features. Because what good is a custom crm powered by Airbase if the star sales guy won’t enter his data?
Hello there! Airtable employee here. I think you’re both right. Many products tend to become bloated and complex as they gain functionality. That being said, this isn’t strictly necessary–and in fact, our philosophy as a design-driven company centers around conceiving the most elegant possible way to implement enhancements to our product without adding (or at least minimizing) incremental complexity overhead. Our head of product Andrew Ofstad did a talk about this earlier this month: https://www.youtube.com/watch?v=UKotko1nAbU