Just some thoughts on “Link to Other Bases”.
I can’t decide if I am confusing this requirement with a more general one of controlled or restricted access to data.
My example is from CRM.
I want only one table of names (and addresses) for every person with whom our organization has a relationship. Those relationships might be patrons, donors, employees, volunteers, actors, vendors, etc.
Controlling access to employee data for an individual who is an employee is an obvious example. Only certain users/collaborators should have the ability to see/change employee-centric data. In fact, even knowing that the individual is an employee might need to be restricted.
But if the employee is also a patron and/or an actor, those relationships would be known to other collaborator/users – without having to duplicate the core information about the person … their name, address, phone number, etc.
Is this “Link to Other Bases” or a request for more granular access control of tables and/or columns?
You’ve touched on a very important point here, which is that it’s incredibly difficult to conceptualize and implement the feature of “linking bases.” When different users have explained to us why they would like to be able to create a link between bases, it’s useful to look at the fundamental problem each person is trying to solve—and it turns out, people’s use cases can be radically different. It’s not clear that in all the cases mentioned in this thread, linking across bases is the best possible solution to that case’s fundamental problem. By this, I mean that linking across bases could be a solution to one person’s particular problem, but it might also create a whole new series of problems. Or it might not! It really depends on the use case.
Dean proposed one possible solution to your problem, which is to have a central/master CRM base. This would make it so that you wouldn’t have to duplicate information about your employees. However, there are still a huge number of potential concerns with how this might overlap with permissions. Suppose you have an outside contractor that needs access to your Company Events base. If they click on a linked record to the Employees base, would they get all the information about that employee, including contact info and other potentially sensitive data? And what if you created a lookup field using the cross-base linked records? This is the sort of situation in which granular and heavily customizable permissions might solve the newly created security problems. But, if we had this granular and heavily customizable permissions system built out, wouldn’t that also eliminate a lot of the need for building cross-base linking in the first place, since many of our users want to use cross-base linking as a form of permissioning?
When thinking about linking bases, we need to take into account every possible implication of the implementation. It’s an extremely complicated problem.
You’ve touched on a very important point here, which is that it’s incredibly difficult to conceptualize and implement the feature of “linking bases.” When different users have explained to us why they would like to be able to create a link between bases, it’s useful to look at the fundamental problem each person is trying to solve—and it turns out, people’s use cases can be radically different. It’s not clear that in all the cases mentioned in this thread, linking across bases is the best possible solution to that case’s fundamental problem. By this, I mean that linking across bases could be a solution to one person’s particular problem, but it might also create a whole new series of problems. Or it might not! It really depends on the use case.
Dean proposed one possible solution to your problem, which is to have a central/master CRM base. This would make it so that you wouldn’t have to duplicate information about your employees. However, there are still a huge number of potential concerns with how this might overlap with permissions. Suppose you have an outside contractor that needs access to your Company Events base. If they click on a linked record to the Employees base, would they get all the information about that employee, including contact info and other potentially sensitive data? And what if you created a lookup field using the cross-base linked records? This is the sort of situation in which granular and heavily customizable permissions might solve the newly created security problems. But, if we had this granular and heavily customizable permissions system built out, wouldn’t that also eliminate a lot of the need for building cross-base linking in the first place, since many of our users want to use cross-base linking as a form of permissioning?
When thinking about linking bases, we need to take into account every possible implication of the implementation. It’s an extremely complicated problem.
Thank you, Katherine.
Tyler, this is a request to allow you to have a central base for something like the CRM in your example, then maintain a separate base entirely for something like Company Events that you can think link to the CRM base and pull participants from.
The desire is to not have to copy the information to a lot of bases that might benefit from the same ore data, while also not cluttering up one base with a ton of different sheets that don’t need to be there simply for the sake of referencing that first table.
Your thought of restricting access to columns is more a permissions thing but has also been requested and acknowledged by the Airtable team. :slightly_smiling_face:
Came here to say this. DRY - Don’t Repeat Yourself.
I want to have one base with all of my employees and then be able to reference them from other bases without having to copy that table every time there’s an HR change.
You’ve touched on a very important point here, which is that it’s incredibly difficult to conceptualize and implement the feature of “linking bases.” When different users have explained to us why they would like to be able to create a link between bases, it’s useful to look at the fundamental problem each person is trying to solve—and it turns out, people’s use cases can be radically different. It’s not clear that in all the cases mentioned in this thread, linking across bases is the best possible solution to that case’s fundamental problem. By this, I mean that linking across bases could be a solution to one person’s particular problem, but it might also create a whole new series of problems. Or it might not! It really depends on the use case.
Dean proposed one possible solution to your problem, which is to have a central/master CRM base. This would make it so that you wouldn’t have to duplicate information about your employees. However, there are still a huge number of potential concerns with how this might overlap with permissions. Suppose you have an outside contractor that needs access to your Company Events base. If they click on a linked record to the Employees base, would they get all the information about that employee, including contact info and other potentially sensitive data? And what if you created a lookup field using the cross-base linked records? This is the sort of situation in which granular and heavily customizable permissions might solve the newly created security problems. But, if we had this granular and heavily customizable permissions system built out, wouldn’t that also eliminate a lot of the need for building cross-base linking in the first place, since many of our users want to use cross-base linking as a form of permissioning?
When thinking about linking bases, we need to take into account every possible implication of the implementation. It’s an extremely complicated problem.
###Implication of Current Design
Just wanted to re-emphasise/rephrase what I seem to recall other users roughly stating (@David_Huck 's post might have put this in my head):
In this discussion we have mentioned a few alternative solutions that were approached from very different angles (views, permissions, etc). But the fact remains that the way airtable is currently built encourages people to build multiple bases centered around a particular subject (HR, Accounting, etc). People will be tempted to think this way while multiple bases are made readily available. Perhaps this was because of the templates that were made availible when we signed up for airtable, or perhaps it’s just the way people work. Either way… it IS the current state of affairs.
###Implications of Permission/View centered design
Now, if “we” (and I say “we” because you at Airtable are so good at making us feel part of this process even though ultimately it is your decision)… If we go the route of using permissions/views to solve problem of sharing data, then this brings up many questions:
-
Does this mean that we will be creating a larger base, organized by permissions/views (as opposed to smaller bases organized by subject matter)?
-
What, then, will be the purpose of having separate bases?
-
Even with multiple large bases, at some point you may want to share data with another base… would it not make sense just to put ALL your data in ONE huge base?
We will need to be re-educated on when to create a new base.
If we go this route, then it seems like we are moving in a direction of making individual bases obsolete (or at least less meaningful), and that is fine, but I just wanted to point that out.
Let me again vote for this feature NOT to happen.
My base is slowly swallowing up more parts of the business. It’s replaced three applications we used to use.
Why? Because usage is high. And right now it’s easier to tell someone to use a particular table and view than direct them to a different base and have the records link.
More granular permissions? Yes. Linking bases? No. The complexity will kill the simplicity.
Wanted to mention another option for those looking to “link” Bases.
On your Base 1 include a field on your “index” that is a formula to display the URL of that record.
Base 2 include a field that can store the URL of the “linking” record.
Have two browsers windows and when you need to “link” drag the URL from Base 1 to Base 2 on the “shared” field.
Obviously doesnt give you any search or reporting capability however will allow for easier Cross-Base data access.
I still firmly believe that Hashim_Warren has it right… One Base to rule them all!
I agree, even if this was capable of looking up data from a Spreadsheet that would work in the most part
Let me again vote for this feature NOT to happen.
My base is slowly swallowing up more parts of the business. It’s replaced three applications we used to use.
Why? Because usage is high. And right now it’s easier to tell someone to use a particular table and view than direct them to a different base and have the records link.
More granular permissions? Yes. Linking bases? No. The complexity will kill the simplicity.
If the feature were ‘optional’, that would work for both camps. :slightly_smiling_face:
If the feature were ‘optional’, that would work for both camps. :slightly_smiling_face:
I agree, I don’t think the option here is to avoid this new feature, I think it’s to find a great way to implement it and not interfere with those who don’t want to use it. If you don’t have a use for linking between bases - don’t use the feature when it’s live. :slightly_smiling_face: But definitely listen to the loud feedback of the many who have found countless ways this would help their processes and workflows. My two cents anyways.
Let me again vote for this feature NOT to happen.
My base is slowly swallowing up more parts of the business. It’s replaced three applications we used to use.
Why? Because usage is high. And right now it’s easier to tell someone to use a particular table and view than direct them to a different base and have the records link.
More granular permissions? Yes. Linking bases? No. The complexity will kill the simplicity.
Hey @Hashim_Warren,
(please excuse the bold portions; not meant to be disrespectful, but merely add emphasis)
I’m in favor of the one large database. However, my concern is what will be done about INTERorganizational information?
Pros / Cons of Permissions/Views
Permissions/views solves the problem of limiting the scope of a base (ie giving other users the ability to view or not view what already exists inside of a particular base). Having one large base with fine tuned permissions / views is beautiful if an organization sees that base as THE central hub where everyone IS going to input data.
Additionally the permission/view solution solves many tangential issues still being raised (see this new post about the desire to collapse/hide lists of tables).
However, what this does not fix is the fact that data which is useful WILL exist and be maintained by other users or organizations… how will that data be most easily/automatically be integrated into THE base?
I love this idea of views/permissions being granular! But, this problem still remains: how will it solve the problem of importing and automatically integrating data from an external source. Thoughts?
The non-profit I work for is using one Airtable base for scholarship applications (with Zapier), and another for keeping track of all the details about our courses. Being able to link the courses to the scholarship applications would be amazingly useful.
Yes please we need this feature.
I also think this would be awesome and would keep my information more organized.
I have read this thread with interest - my background is a ‘database developer’ - always with tools like Access, Filemaker and most recently Access Web Apps.
There’s a lot to like about Airbase but also some issues which this thread encompasses. The suggestion of cross-base links is perfectly sensible and would be useful - but it sounds as though it would be very difficult to achieve. For me the biggest win would be the ability to control access in a better way so that one could deal safely with different use-cases.
My main expertise is HR software, a business I have been in for over 25 years - 15 of which as founder and CEO of an HR software supplier here in the UK which I sold. HR is a great example of how the same database needs secure access for different groups of users:
HR Users - these users generally have access to all data for all staff
Managers - would have access to some of their own data plus their team members
Employees - Only have access to some of their own data
Each user group would need their own User Interface with just the items they have access to showing - and with data secured (to field level) appropriately. The latter can be done by using some read only fields on the forms they have access to - or through the database itself if possible.
There are also processes which are unique to each type of user - for example employees can request leave - to be approved by others. In this example, the Approval field(s) would only be available to approvers.
Translating this to Airtable and this conversation, I think the most suitable approach at this point is to build out a security model which allows the UI to adapt to the user logging in, hiding options that aren’t available etc. Note that generally you would NOT want most users able to change ANYTHING in the design of the app or it’s views - just use it.
Another aspect of HR applications is that they have a LOT of tables - our current HR app in the Microsoft Store has 80 - there are many other examples which would have even more. To make this usable in Airtable there would need to be a way of hiding tables from the table menu bar and only accessing them from view of other tables (or buttons on those views), some other menu option (a table manager perhaps) - possibly only directly accessible by a Creator user type.
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. :grinning_face_with_smiling_eyes:
Yes, for us we’d love to be able to enter information once, such as a new client- and have it populate across all the databases where the ‘client’ variable is necessary. i.e. We enter a new client on the client master list which then links and populates that field in the accounting table, and project management list etc.
Can you make this the #1 priority for your Roadmap? That’s all you’re missing for most of us. Keep it simple in the beginning where you can only link within bases.
Would happily upgrade and pay for this feature!
In fact, Another way would be to be able to have a different group of tables inside one base. And it would help to have that shown visually by having different colors on the top of the base where you see all tables. Imagine having 2, 3, 3… row of table tabs for each group, one on top of each other. And you could give different permissions for each group. Would that be easier/feasible?
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. :grinning_face_with_smiling_eyes:
- I dont want all users to see all data
- I dont want all users to see all data
Who proposed allowing “all users to see all data?”
Please please please add the capability to link between bases! I don’t want to risk overloading one base with so many tables; sometimes having more than two levels of categorization (such as the two you can create when you make a base, i.e. Base:Table) on a project warrants creating distinct bases (i.e. Big Project:Aspect 1:[A Distinct Set of Tables]; Big Project:Aspect 2:[A Distinct Set of Tables]).
This capability, along with Airtable’s current trajectory, would make it nigh unstoppable. I want to dump all my data into Airtable, but view things in a narrow enough scope to be manageable.
Just wanted to let everyone know that we are reading and discussing your responses. Thanks again, everybody, for the incredibly insightful feedback and for the in-depth discussions of your workflows/use cases. :slightly_smiling_face:
A sufficient implementation for my needs would be the ability to manipulate the access to the various tables. If I can restrict table access, I can tailor the interface to the user. By building ‘gates’ on sensitive info by using lookup on referenced hidden tables I can control the level of access.
This would be great for me because I currently maintain 2 bases so that inventory cannot see project financial information. If I could hide tables as ‘table sets’ and then give access to the table set, I would have the control similar to linking bases, and I could then join bases that need cross access.
Doable?
Michael
PS This is the biggest advance in the last 5 years for sure. AWESOME job.
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. :grinning_face_with_smiling_eyes:
25 years ago in an x-Base DBMS we developed applications that handled millions of records in upwards of 70 tables for an aircraft manufacturer; we wrote shop manuals for fleet mechanics. We needed to include data from an engineering database that gets updated overnight 6 days each week. We wrote a custom extract program (with permission from the engineering department’s IT group, of course) of selected data organized into forms we could upload into “fill, use, and empty” tables we thought of as temporary data tanks. Creating and then dumping temporary tables has limitless power and was a standard practice for every programmer and application designer I went to for advice. Our extracts ran every night right after engineering’s tables updated, and every morning when we walked into the office all the external data we needed was at the ready. I suggest this as a sample of a method that solved the problem without introducing data duplication or our-of-synch data entries. I’m thinking that some people who commented might be able to create an output report of selected data from the 2nd database specifically formatted to load a table in their primary database. This bypasses issues with security and with accidentally editing another database’s records, plus it doesn’t require the database engine to manipulate complicated links.
As an afterthought, I’m new to Airtable as of this week (very happy so far), so I don’t yet know its limitations, but in my own experience I never met a database that couldn’t take on one more table!
This is a possible solution that others have hinted at. If there could be a way to allow for a table to be duplicated to another database and that when changes to the source database are made that are also made in batch or on the fly to all the duplicate databases tables that would make a bunch of things possible.
Plus if you could select the fields that you want copied/duplicated that would even be better.
Because then the source table can be protected in the source database. The duplicate table data would be a special read only for all in the new database. This can then be used to lookup information, updated records, link tables without the many problems. If the source is removed or changed in a way that make the link stop the duplicate could remain static but report an error. Changes would not be allowed the other way.
You could do this by batch loading the table over and over but I think that would mess up the links.
If anyone know of way of doing this now please let me know.
Would be great to at least have a table search to use if adding a dozen+ tables to a base as a workaround, and way to hide most of the tables so its not taking up multiple rows at top of screen.
