Skip to main content

Hi, I have a question about some app architecture that I wonder if anyone might have suggestions or opinions about? The short version is: is it better to pull AT data into an outside app, or to instead try and build plugins / overlays within AT (somehow?) ?

 

 

Longer version: I am an engineer (not the software kind) and architect (also not the software kind). I LOVE AirTable. We use it religiously in our firm and it works GREAT for managing building data (pumps, fans, windows, glass, materials, rooms, ventilation flow-rates, etc, etc...)., We have built all sorts of tools to pull AT data down into our local Building Information Models (BIM) as we work. 

I’ve been working on a client-facing app for BIM data display, and so far what I have is a basic React App which pulls in a project’s AT data and displays it in tables for the client. So thats also fine. But NOW I am starting to add ‘creation’ tools to this app,  and I’m wondering if instead there is a way to build my app into AT, rather than pulling AT data into my outside app? 

Context: For some things we have found that is SOOOooo much easier to work with graphical widgets rather than tabular data. Not all things, but some things. For instance: I have built us a ‘window builder’ which allows us to graphically create windows, and then assign the data for glazing and frame types from our AT material collections. 

 

While we *CAN* (and did) used to do this in tables within AT, having the picture just makes it so much easier to see what we’re doing, and trouble-shoot (which frame goes to which edge, etc...).

We do similar things with ‘assemblies’ (layers of materials, organized graphically but connected to a backend of  material data in AT).

 

So, this is all ok… but in my app I really miss all the nice table-tools from AT (copy, paste, new column, filter, sort, etc, etc, etc). I was starting to think about how to implement copy, paste, undo, sort, filter, blah, blah, - but they thought maybe I was all upside down here, and that instead of replicating this AT behavior in a new app, could I just bring my graphical interface bits into AT instead?

Question: Is there any way to build any sort of graphical ‘widget’ within AT (a picture of a thing where some of the elements are associated to AT records)? In an ‘Interface’ perhaps? I’m not as familiar with those - but maybe they allow for this sort of use case?

 

Any thoughts or suggestions are appreciated. 

all the best, 

​@ed_p_may

 

Custom extensions are the only place in all of Airtable where highly-experienced JavaScript developers can create graphical widgets that pull data from their Airtable bases.

Currently, extensions only work in the data layer. Extensions are not currently available in interfaces, but they’re coming soon — hopefully in 2026.

You can read more about it here, and sign up for the beta:: 

Hope this helps!

If you have a budget and you’d like to hire the best Airtable consultant to help you with this or anything else that is Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld

Question: Is there any way to build any sort of graphical ‘widget’ within AT (a picture of a thing where some of the elements are associated to AT records)? In an ‘Interface’ perhaps? I’m not as familiar with those - but maybe they allow for this sort of use case?

Yeap, you can write your own apps for this!  Airtable calls’em Extensions and you can either build them for your base (accessible via Extensions at the top right) or for your Interface (accessible as an element):

Base: https://airtable.com/developers/extensions

Interface: https://airtable.com/developers/interface-extensions

The main consideration between building it on Base or Interface is who has access to it I think; if you did it in the Base then whoever was using the app would need access to the entire Base.  

Uses JavaScript, so you can probably port most of your current code over and just change the way it’s getting data!

---

As an aside, that UI looks really clean and similar to the Airtable stuff, nice work man.  After you port it over new users will just assume that it’s part of Airtable’s core functionality heh

 

ah - Extensions! Super cool. Thanks so much ​@TheTimeSavingCo  and ​@ScottWorld  - I’ll take a deep dive into extensions and see what I can do with that. thanks for the advice and the kind words!

-E

FWIW: Extensions *almost* work for us. The dev process is fine, and everything appears to work well. But deploying the extension to our Bases appears as though it won’t work, which means they really aren’t a viable solution for us right now.

If I have to personally, manually deploy the extension every single time someone on our team creates a new base and wants to use it, thats a non-starter for us I’m afraid. Unless I misunderstand something about deploying custom extensions? https://airtable.com/developers/extensions/guides/run-in-multiple-bases 

Our extension isn’t generic enough to go in the ‘marketplace’ (I’m not averse to that, but it just wouldn’t make any sense or work for anyone outside our team) and there doesn’t appear to be any other way to deploy the extension into our different Workspace Bases?

Extensions seem like a promising feature though. Maybe someday once they are real we can revisit them. But  unfortunately it appears that they are not quite fully baked just yet.

Maybe I’m missing something here though?

​@ed_p_may 

Sorry, I don’t know much about deploying custom extensions, but that didn’t sound right when you said that your team is continually creating new bases. Is there a reason for that?

The typical setup is that an entire organization would be using a very limited number of bases. This makes it much easier for you to deploy interfaces, automations, security restrictions, underlying database architecture changes, etc.

It wouldn’t be efficient to keep creating new bases for each new client project, because you would lose the flexibility to roll out changes in bulk. Also, you can always use interfaces as a security layer so that clients/employees can only see the projects that they are allowed to see.

- ScottWorld, Expert Airtable Consultant

​@ed_p_may Ah yeah, Base extensions need to be added manually I’m afraid

Interface Extensions can be installed by anyone in your organization / workspace though, so perhaps you could try that?

https://airtable.com/developers/interface-extensions/guides/polishing-your-extension

 that didn’t sound right when you said that your team is continually creating new bases. Is there a reason for that?

I wouldn’t be at all surprised to learn that we’ve got our whole setup inside-out or upside-down somehow 😉

But yes: currently we have a new ‘Base’ for each Project (for us, a Project=a single Building), all inside of a single company-wide ‘Workspace’. This has (so far) worked really, really well for us. One of the things we like about AT vs some other solutions we’ve tried is the ability to customize the Tables and fields for a specific project’s needs / attributes. While there are many, many similarities across projects, there seem to inevitably be many unique aspects as well - and so having that project-level customization has been nice for us. 

But yes: you are correct that this does, I guess, mean that interfaces, automations, and extensions become a challenge. The “run-in-multiple-bases” solution that they have seems to work pretty well when I tested it - its just the manual .json file editing and manual remote-deploy that would become a problem (not a HUGE problem - but I can see it becoming a bottle-neck to have to do that manually each time). In an ideal scenario (for us) our users could find and add our internal company-wide extensions through the ‘Add Extension’ panel. Hopefully that comes one the “run-in-multiple-bases” moves out of Beta stage. 

thanks for the input though! Super helpful food for thought.  

​@ed_p_may 

Cool, thanks for explaining! Yeah, it sounds like you have figured out the best setup — if each base is dedicated to an entire building (and there are also unique customizations for each building), it sounds like it is a great approach to have each building in its own base!

- ScottWorld, Expert Airtable Consultant

My two cents, the higher the number of edge cases an org has, the bigger is the case for a standardised data schema. I’d try to find a way to handle all the edge cases under one base or within a set of a few interlinked bases.

With you having a separate base for each project, the entire interface based workflow is a non-starter. And it is not just Airtable, any other tool as well will have the same issue. I dont’ think there’s way to add standard interfaces to a database that could change at any time.

Amazing!!!

Terms & ConditionsAccessibility statement