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.

[Christiaan_West]

Record access control would allow users to see only their records and not records of other users. This is another way of solving the problem that other are seeking to solve with cross-base linking.

For reference, check out how Knack implementer it http://helpdesk.knackhq.com/support/solutions/articles/5000443970-showing-records-connected-to-the-l...

[Matthew_Billiod]

Hey Katherine,

• I preface this reply with Praises:
  Both this software and the website are great. I love all the fine detail you all put into your products: the phone app (extremely easy to add a picture, tag items, add multiple tags to a single field, link to other table and see the related content of that table), airtables online (same praises as the phone app), and your website (the commenting interface, change logs, drop down to view replies, pop-up to see the original post, etc)… everything seems to just work and be intuitive (something that is becoming somewhat rare in the android and google world).

• In short, we appreciate you sharing why you have not yet implemented this feature yet. We certainly understand that it is a huge project and appreciate you all informing us of that fact, and we also appreciate you wanting to implement it correctly. Thanks for being a good communicator and sharing your companies concerns before diving into this request.

Now, I want to second the comment of @Polen 's (April 6th, 5:20pm) and @Sarah_Cliff (April 15th, 7:27am): The request to link to other bases is primarily rooted in these desires:

1. Permissions (ie the granting of read or write access of different parts of data to various users)

2. Workflow! (@Sarah_Cliff, thanks for doing a great job expressing these points)

• workflow+permissioning: It is easier to share a whole base with individuals, rather than go thru every table in a base and set permissions.

• workflow+navigation. It feels very cluttered to flip through many tables in one large base (as Katherine_Duh already suggested was a possible reason for the request) .

• Intuitively, I want to click on a base by department and see the related tables (ex, Contracting, Billing, or Customer Relations).

  • this could be achieved possibly by custom views (hiding certain tables upon clicking on that view)

1. Like @Polen stated, perhaps some of the base linking could be gotten around by using a report function.
2. But, like David_Huck stated, the workflow issue, and the desire for multiple bases seems to stem from how you currently have your templates setup: "The current template system encourages a proliferation of bases whereas that " does not seem to be the way in which you are herein encouraging us to use airtables.

Now, I would like to point out that even as things stand now, multiple bases are great! And if you decide to use finer permission management and some sort of report/view to achieve meet objectives behind this feature request, we will be exceedingly happy. Still, as we move forward in this disucssion, I would like us to consider this question: if we can throw all of our tables in one base, what then are multiple bases for?

PS
auroraafable had a great point: multiple bases could allow users to get around the max record requirement. Hopefully you… price the adding of this feature accordingly, and hopefully you wont spend too much resources on something that you wont be reimbursed for, unless you are feeling benevolent :relaxed:

[Sarah_Cliff]

Thanks for the nod!

Also, I thought of this:
If getting around paying is the primary concern with implementing this feature, make this a feature for only paid accounts. Problem solved.

[Matthew_Billiod]

Hey Sarah,

Yeah, I was thinking the same thing: this feature should be a pro-feature, with a 30 day trial.

However, I really do not believe they are terribly concerned with people getting around the record limit (at least that is not their primary concern). Instead, a change/implementation of this caliber is a huge change in programmatic structure if it was not already accounted for, especially if they are considering implementing the same sorts of features between each base that they have between each table.

For our company’s concerns, we would not mind if they did NOT implement all of those fancy features, and instead simply pulled & pushed information between bases. We would be interested in the pro-version if that simple interface were implemented. Still, even with that simple scenario, permission issues will complicate the implementation of this feature.

[Don_Thompson]

Yet another +1 for this feature. Would really help clean up the whole structure of my base.

[Katherine_Duh]

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:

[David_Hobbs]

I think Zapier has added multiple steps as a feature recently, this could work?

[Polen]

Multi step zaps are a partial solution and only in some scenarios. In my experience, when we need to sync (which our biggest need) data among bases is when we’re most at risk using Zapier as we end up with a lot of data that’s duplicated and that needs to be updated across a few bases. They recently (if I’m not mistaken) added Find Record and Update Record as actions, allowing for some kind of sync. However, there’s a limit of how many records they can retrieve at a time from Airtable (100 at least for New in View as trigger), so zaps with, say, 15 minutes in between runs may end up with errors if you work with many records.

Re: @Alexander_Sorokin’s comment – He’s got it right, there are ways to play around with Zapier not to get blank records and such, but limitations with New in View trigger (firing only once ever) cause the need of additional redundant zaps (and views) and potential errors (like when a user causes a record to enter a view by mistake, then corrects it–> when the records later enters the view legitimately, it won’t fire the zap) that can render the whole zap idea kinda useless, as manual review and updating has to be done. We just are super careful when we touch fields that are connected with these zaps. I like Zapier but it cannot beat functionality built in Airtable. We love Airtable and we know they’ll find an elegant and effective solution for us… hopefully some time soon.

[Jeremy_Sookhoo]

Another solution that hasn’t been discussed in depth yet on this thread is to improve accessibility. Essentially, many users on this thread are asking to be able to click on one icon and edit some information, and then have that information linked when they click on a different icon and edit a different type of information.

It is so convenient to open a base - there is a customizable icon and also a URL to bookmark. However, users that have a large and sophisticated base may need to access it for 3-4 distinct workstreams. Thus, a user may need to access and navigate the entire base (potentially tedious) for a few routine edits that can be made to a single table. If accessing a single table or a subset of tables/views was as quick and convenient as accessing the entire base, then this issue may be resolved for some users.

In this world of apps, widgets, bookmarks, and shortcuts, users may want the simplicity of entering a URL or clicking an icon to complete a task, project, or workflow (i.e., edit a table or a pre-defined configuration of views and tables within a base, with the rest of the base hidden). This would give users the experience and “look and feel” of opening up a new base, even though they are just seeing a portion a larger base that is hidden and interlinked in the back end.

[Petr_Murmak]

I believe that for vast majority reasons why people need links to other bases I have a solution which would be the easiest to implement and also very easy to use and very clear from rights point of view. Imagine this scenario:

When I want to link to other base what I will do is following:

I will make ghost of table from the other base into current base.
This ghost table will have exactly the same content as original table in the other base.
This ghost table is read only. So only people with an access to the original table in the other base can make changes (which will automatically propagate into all it’s ghosts).
Once I have ghost table in current base I can link to it.

And the best would be if this ghost table would be based not just on the table in the other base, but also it’s view. So in the ghost table there would be visible only records which belongs to some view.

So for example imagine following scenario:

I have base Sources with tables like Employees, Products etc. In this base I would keep sources for all shared tables.

Than I have base Sales where I need to link to our products from some tables. For that I would make ghost table Products which will be identical to Sources/Products. But in Sales base Products will be read only. And I can link to it from any table in Sales.

If I would need to track who sold what I would need to make ghost table from Sources/Employees and I will call it Sellers. But if in our company we have a lot of people and only handful of them can actually sell something, I would prefer to have just those in Sellers table. So instead of ghosting whole Employees table I would like to make Sellers ghost of Sales team view from Employees table which will show only right people.

I hope that I made my example clear and understandable.