Global Fields for Reuse

[Alex_Murillo]

As far as I can tell, Airtable does not offer the ability to create global fields (within an Account) that can be reused across all Bases. This is a critical feature if I’m going to create a Field that would essentially be reused in multiple Tables across multiple Bases.

The primary idea for a Global Field is to create it once, and reuse it multiple times. Additionally, if I add/remove items in the field (e.g. a Select Field type) then all tables using that field would be updated automatically.

I realize I could create a template and then all future Bases could be created from that table, and hence include that field, but this does not cover the field update scenario.

[David_Deborin]

Have you found a workaround solution to this? I’m having the same problem.

I want to be able to call scripts in other scripts. Essentially, some sort of global function or variable capability would be a HUGE game-changer. This is essential for developers who plan on writing many scripts.

I made a post about this just now - here’s the link, maybe we push the Airtable team to do something about it:

Can I call a script within another script? Scripting app

I’m a developer and plan on writing A LOT of different scripts. Let’s say I create a script that sums the values of a column. I plan on using this script (function) in multiple scripts. Is there a way I can essentially call this script in separate scripts instead of having to copy and paste code all the time? In other words, can I create global functions? Can I call a script in another script? The same concept applies to global variables. My script will use the name of one of my columns. But …

[Avana_Vana]

I believe you could just create a table, and store each field in the table as rows containing columns for the field’s name, its type, its options, and its description (if you need it), as JSON, and then in your script you just retrieve each column’s values, and use JSON.parse() to convert the stringified JSON text stored in the column to JavaScript objects, for instance, the column’s configuration options, and then you just call table.createFieldAsync(name, type, JSON.parse(options), description) to create the field.

My use case for global variables is more basic. I have several scripts that utilize API calls to the same base URL, and sometimes I need to change the baseURL. As I have more than 3 dozen automations and apps in one base, this can be very tedious and error-prone. It would be so much easier to just be able to define custom global variables, alongside the built-in globals like session, base, etc.

I mean, I could do something similar to what I proposed above, by just making a new table called “Global Variables” containing 2 columns, key and value, and then just get the globals from that table, but this requires adding a whole new asynchronous table lookup call to the script—just feels like overkill for such a basic need. Also, my base is open to the public and I don’t want to expose the back-end guts of the automation to the public. I can’t believe they haven’t implemented a way to hide certain tables according to permissions yet.

But yes, global variables would be extremely, extremely useful and I feel it’s just a basic, necessary feature.