Link to other base


#22

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:

  1. 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)?

  2. 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?

  3. (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. :smile:


Collapse/Hide list of tables, to maximize work area
Want Collaborator to only see own tasks
#23

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:

  1. 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”

  2. 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

  3. 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


Collapse/Hide list of tables, to maximize work area
Private Tables for Creator
#24

+1
I see some community benefits like reduced tables redundancy and by the way, cloud space saving.


#26

+1 me too. this would help us a lot.


#27

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!


#28

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


#29

@auroraafable
Hum… really ???
-1

@auroraafable
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.


#30

@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

Update
Okay, I edited it. Better? :wink:


#31

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!


#32

@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!


#33

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.


#34

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.


#35

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 :slight_smile: while the rest of us drive ourselves crazy linking bases. :confused:

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. :relaxed:


#36

@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?


#37

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


Advanced User Permissions
#38

Then we’ll have to agree to disagree, and I stand by my Excel example. I don’t think anyone would say that Excel is complicated to use. Is the first time user overwhelmed by complex features like pivot tables? Absolutely not, because the advanced features don’t make the basic features any more complicated. In fact, I would guess half of all Excel users don’t even know some of those complicated features exist.

I agree with you on one point - adoption is critical. But if the software is designed properly, and so far Airtable is doing a great job of that, then adding more features doesn’t complicate the user experience and won’t impede adoption. Features should be added based on consumer demand to increase adoption. Right now, in my organization, the inability to link bases is currently preventing us from expanding our use of Airtable, so adding that feature would certainly increase adoption here.


#39

Being able to link bases would be unendingly useful. I work for a major publisher as part of the marketing/publicity. We all work on the same books, but our work is completely separate depending on what team we work on (publicity, online, retail, school & library - and within those teams there are more teams) and is way too complex to all work within the same base as it would results in somewhere around 100 different tables or more within one base - just not workable. It would be great to have one “hub” base where we could store book, author, and other major information like budgets which currently we all have to keep separately. If we had a hub, the department assistant could be responsible for updating all of the hub information, which would update automatically across our individual bases. The hub base would also be able to read information across the rest of them like how much money we’ve spent across all of our teams, etc that is relevant for the higher ups but not relevant for people on the individual teams. Essentially, taking a larger vs more granular view for teams vs departments.


#40

@Keri_Sprinkle i hope you don’t mind a little respectful back and forth on this…

Excel is a perfect example of what I don’t want. The lack of structure hinders collaboration.

What happens is the spreadsheet maker creates her own design of the spreadsheet and ends up “owning” it for life. No one knows why she used cell highlighting instead of adding a new column, or why subtotals are in their own sheet.

This means no one can add data to the spreadsheet or contribute to its design. And the Owner gets stuck accepting data from team members over email, chat, a conversations.


#41

Just thought I’d chime-in, because we’re using Airtable quite heavily now and starting to run into a few limitations that interbase linking would solve.

Our use case goes something like this:

We started using Airtable to manage product pages across multiple websites, tracking which sites each page is live on, where it’s been approved and what sort of content it involves.

The first limitation is that we really want the whole team to be able to see this info and apply filters, without being able to edit data willy-nilly and messing up our beautiful creation. Also: some members, we’d like to be able to edit the “approved” field, without editing any others. Granular sharing permissions would be very useful here.

Right now, we’re sharing private links via Google Sheets so people have access to the views appropriate to themselves and can filter records without affecting everyone else. This is not ideal at all.

Pause for breath. And onwards…

Once we had a powerful database of ‘page content’ set up, we moved onto adding ‘email content’ and linking it to the applicable ‘page content’ record. This works pretty well as is, but again, it’d be lovely to be able to decide who sees content from this table. I’m not sure the sales team really care about it.

Next step was creating a table for all current site issues. We’d assign an issue to a page and keep track of whether the issue was ‘open’ ‘solved’ ‘pending’ etc.

As you can see, we’re moving away from the primary use of the base, and it’d probably be nice to split it into two at this point.

Next step was having a table where Customer Service could log complaints and requests. Then our content team could come along, create an issue and tag the appropriate request. Things are starting to get a bit Inception now, but this means the Customer Service team can easily track the status of their requests. Lovely stuff, but now we’re definitely in multiple base territory.

Lastly, I want to start tagging an issue with the team member who’s working on it, so we don’t start crossing wires. Ideally, we’d have a third base now for company employees.

I hope that, in a rambling kind of way, I’ve highlighted some real-use limitations of Airtable (but also showed just how crazy-useful it is for a company with a ton of data and a big need for collaboration).

My wish list? Interbase linking. Granular permissions. Folders for views.

Love from an Airtable evangelist,

Rob


#42

The benefit to our organization is #3 and its because of needing to manage who has access to what tables in a base. For example, I’d love a master NameAddress table … for employees, clients, patrons, vendors, etc. All names and addresses in one and only one place. But, I can’t keep employee-centric data tables (with salaries, etc.) in the same base that addresses clients and patrons. I need collaboration or visibility/use at the table level. (We’d love to control at the record level. Like giving an employee some data management control over some of their own data records). [But I could vote for #1 depending on how it was implemented. :wink: ]