Link to other base

[John_Bacino]

So happy that someone finally filled the void left by Dabble DB.

One of the features I found most useful there, but can’t seem to do in Airtable, is linking to entries in another Base. Often, one will have multiple bases which handle distinct aspects of a business or project, but in which one piece of data overlaps.

Example: A political campaign may want Bases for contacting voters, managing events, and recording donations. Those are distinct domains which need their own Bases, but which could benefit from linking parts of them together. For example, it would be great to link donations to the event they occurred at, or voters to donations, or record who attended each event.

In Airtable at present one has to either cram all of those bases into one, or foregoe the linkage which makes this software so great. It may seem like a small thing, but once you can link bases, the sky is really the limit.

[Dianna_Atchison]

Choice #2 for me. I have different tables for different agents / districts for privacy reasons. I am currently going through the laborious task of moving some agent’s entries to different tables because they have been re-assigned to different districts. Still, I would like to access the data in one place rather than across different tables. #2 would allow me to re-assign agents quickly and still provide the privacy needed and the single table for me.

Thank you for an amazing product!

[Tech_Tylercivic]

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?

[Tech_Tylercivic]

… Or is this just another veiled request for being able to change/delete records from URL-based views?

[Dean_Toland]

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:

[Tech_Tylercivic]

Thanks, Dean. — Richard York

[Katherine_Duh]

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.

[Tech_Tylercivic]

Thank you, Katherine.

[Christian_Rodri]

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.

[Matthew_Billiod]

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

[Hashim_Warren]

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.