Can Airtable's own "Export CSV" be triggered via a script?

[Markus_Wernig]

Here’s my thinking. I like the simplicity of Airtable’s own “Export CSV” function. Data in a spreadsheet as a simple backup is all I am after.

If “Export CSV” could be triggered via a script, the entire process could be automated. A new record could be the trigger to run this script.

Does anyone know if this is even possible?
Thank you!

[Ahmed_Elagami]

Hi Markus
Glad that would help, I believe when you download a CSV from a linked data it will keep as text, it won’t be linked anymore, it’s exactly the same if you create a side column " Formula" Type and you just type the same linked column it will read it as plain text.
I guess that would be always the case if you uploaded a backed-up CSV file to a new Airtable base.

Thanks
Ahmed

[Markus_Wernig]

Hi @Ahmed_Elagami, I just heard back from On2Air. It’s the same problem as with the another automated CSV backup solution through miniextensions.com (which offer the exact same thing and even more solutions for a flat rate per month, regardless of the amount of records):

When backed up as CSV through an outside service (on2air.com for example), a linked record field does not come across as a name (data) but as an ID. That’s how Airtable’s CSV API works.

WRITER (Airtable Linked Field) | Steven King - becomes
WRITER (CSV) | recgbyplnp4Qy7BOVQ (CSV) - when exported through Airtable’s CSV API (which on2air.com or Miniextensions.com use).

The “workaround” is to add an extra field next to every linked record field and configure it either as a “lookup” or as a “formula” field (pointing to the linked field). That way the additional field shows actual “text” that doesn’t turn into garbage text once exported.

I’ve had that setup with miniextensions.com. It’s just that my inventory table has so many fields (120+) that adding even more just to work around the “garbage text” problem makes it a nightmare to work with. (If only Airtable had a better way to re-arrange / rename tables with lots of fields…)

Airtable’s own “Export to CSV” function doesn’t have that “garbage text” problem. All they’d have to do is allow us to use this function as an action with their new automations.
And no, attachments would not get backed up that way, but miniextensions.com has a stand-alone automated solution for that too and it works really well.

[Justin_Barrett]

Markus_Wernig:

That’s how Airtable’s CSV API works.

To clarify, there is no CSV API for Airtable. They only have one API, which is their standard REST API. All third-party services that access Airtable data use this same API: on2Air, miniExtensions, Integromat, Zapier, etc.

[Markus_Wernig]

Thanks for clarifying, @Justin_Barrett - I am not a coder, so please excuse my ignorance :winking_face: .
For us “regular users” Airtable can quickly turn into a pretty complex beast. The moment we want more than a simple base, we couldn’t do it without the help of all the experienced pros on this forum! So thank you!

[Bill_French]

Markus_Wernig:

The “workaround” is to add an extra field next to every linked record field and configure it either as a “lookup” or as a “formula” field (pointing to the linked field). That way the additional field shows actual “text” that doesn’t turn into garbage text once exported.

One person’s garbage is another person’s gold. I don’t see this needing a workaround unless you intend to flatten (denormalize) the data.

Let’s be honest, the record IDs exist because you wanted the data model to support relational connectedness, right? Now you expect Airtable to ignore that and give you something different when exporting said data.

Any database expert charged with the responsibility of reinstantiating your data model in a recovery Airtable crisis or in a new relational database system will need the record IDs, not the text representations. As such, the purpose of the exports should be clearly defined - is it for disaster recovery? Reuse in a spreadsheet?

Markus_Wernig:

If only Airtable had a better way to re-arrange / rename tables with lots of fields…

It does actually, and by “better” I assume you mean different. :winking_face: The way I manage to create alternate export formats is to:

1. Define the export requirements in the context of very specific requirements.
2. Use the API or Script Blocks to build precisely the export format required.

Markus_Wernig:

Airtable’s own “Export to CSV” function doesn’t have that “garbage text” problem.

Indeed, because in that context, it assumes you want the data, not a representation of the linking relationships (which should not be regarded as “garbage text”). More precisely, it’s not helpful for the use case you may have in mind.

But, if that use case is for disaster or crisis recovery and restoration, that garbage text is going to turn out to be little golden eggs.

[Markus_Wernig]

Thanks, @Bill.French for clarifying. Everything you say is of course correct, however - and maybe I should have been clearer as to why I need “normalized data” instead of record IDs. You are again correct that there are different scenarios for when record IDs and when text representations are needed.

I run a music library / publishing company. All of our music tracks come with a ton of metadata that has grown to a whopping 120 fields per record. This is not by choice. Various clients, sub publishers require these fields. We need to export data in various spreadsheet configurations depending on where our music is uploaded to.

So I am faced with two questions - what’s the easiest way to re-arrange this vast number of fields to fit various spreadsheet requirements? And how do I make sure that I am getting text-data on the other end and not record IDs?

Bill.French:

The way I manage to create alternate export formats is to:

1. Define the export requirements in the context of very specific requirements.
2. Use the API or Script Blocks to build precisely the export format required.

That may be easy for you, but for every non-database expert / regular Airtable user, your “run everything through a script” way is an insurmountable task. We’re stuck with the manual “re-arrange 120 fields”, “export everything by-hand” way.

I have posted a job offer to write a CSV database export script - so far, no luck in finding somebody. :man_shrugging:t3:

Let’s not forget one thing - Airtable was created to be “the database for the rest of us”… :winking_face:

[Markus_Wernig]

One more thing, @Bill.French, about arranging 120 fields in a table, so that I can export different CSVs for different scenarios.

Isn’t that exactly why Airtable created “views”? So that we, the regular users, do not have to be database-experts who can take care of these things via custom scripts.

I think it’s fair for me to think about user-friendly ways to wrangle 120 fields into a new order. Airtable’s “hidden fields” drop-down menu is pretty good already. Lots of ways for regular users to move things around and turn them on and off. It just wasn’t built with 120 fields in mind. :winking_face:

I am still open to outside help. I am always looking for ways to make things simpler, more user-friendly and more time-saving. And I am also not averse to getting into the habit of working with scripts.

[Bill_French]

Markus_Wernig:

Isn’t that exactly why Airtable created “views”? So that we, the regular users , do not have to be database-experts who can take care of these things via custom scripts.

I’m not sure I understand the connection to views - I was commenting solely on the two extraction behaviours - one with record IDs and another with field transformations.

1. Export is typically considered the “consumerized” CSV version for people who just want the data to use elsewhere.
2. Snapshots (or backups) are just that; they are intended to give you a chance to recover in the event of data loss and record IDs are crucial for that step. As such, I was simply making the distinction that it’s not “garbage text”.

Markus_Wernig:

I think it’s fair for me to think about user-friendly ways to wrangle 120 fields into a new order.

Indeed. All conversations here are fair. I am only suggesting that it’s unfair to refer to record IDs as “garbage text” because in some [CSV] use cases, it is the opposite of garbage. ;-).

[kuovonne]

Justin_Barrett:

They only have one API, which is their standard REST API. All third-party services that access Airtable data use this same API: on2Air, miniExtensions, Integromat, Zapier, etc.

While all third party services use some form of API, the don’t necessarily use the same API. Evidence suggests that Zapier and some other services use a different, non-public API with more features.

[Bill_French]

kuovonne:

While all third party services use some form of API, the don’t necessarily use the same API.

And this is most evident (as an example of secret APIs) in this long-running attachment issue where we can see and replicate the failure in the public API, but not via Zapier.