Automating Airtable Scripts

Welcome to the Airtable community!

When creating an automation script, you can copy/paste the script code into the script editor. However, many scripts that are written for Scripting App cannot be used as-is in an automation. The 'Convert URL’s To Attachments’ script would need major changes to be able to be used in an automation. In fact, the changes are so dramatic, that it may be easier to write a new script from scratch.

If you are replacing attachments every hour, you may also be using up your attachment storage limit rather quickly. Old deleted attachments are not automatically deleted by Airtable and continue to count towards your base’s quota. Airtable has not published now long old, deleted attachments remain, but a reasonable guess is at least one year (the length of revision history) without manual intervention by support.

Hey there!

If you want an easier way to do this, you can use the Convert URL to Attachment Function in the On2Air Actions app.

You can use it inside an Automation. It will automatically generate a script for you. All you need to do is then add the script in the ‘Run Script’ option in your automation.

With Actions, you also get an additional 60+ functions for Airtable

So you are saying that if I have a field with a URL - and I download the attachment in that field - and then refresh my data so that the attachment is no longer in the field - - that the attachment is still stored somewhere but I cannot see/use it and it counts towards some storage quota ?

If i am going to create a script for this, is there some existing function to download an attachment from a url that I can work from? Was not able to find

Yes. You can test this out for yourself.

1. Upload an attachment. Get the url for where the attachment is stored on Airtable’s servers by using a formula field with the attachment field name.


2. Copy the url to a temporary location outside of Airtable.


3. Delete that attachment from Airtable.


4. In a browser window, view the url. The attachment will still be there.

With a Pro plan, you can have up to 20GB of attachment storage per base. Depending on the size of the attachments, this can be used up quickly, especially if you are creating new attachments every hour.

If you are interested in writing your own script, you can see the developer reference documentation. Here is the format for an attachment field.

I’ve not delved into the guts of revision history yet, but this discussion has piqued my interest, partly because I’m trying to help a client who has hit an attachment limit. Does it affect the quota when record revision history is deleted? I’m running a test now to see for myself, but the stats on my workspace settings page aren’t refreshing as promptly as I’d hoped (and I’ve reloaded the page multiple times). The base where I’m running the test shows 6.9MB of attachments, but that only accounts for the existing attachments before the 112MB file that I just added. I want to see how that indicator changes when I delete the test record (and its attachment) along with record revision history, and I hope that I don’t have to wait a full day for that figure to refresh.

Edit: it just updated. Maybe it’s a similar 10- to 15-minute refresh frequency like so many other things. I’ll report back once I see the final results from my test.

It worked. The record and its attachment are gone, record revision history was deleted, and that base is showing its original attachment size of 6.9MB on the workspace settings page.

Awesome. Thanks for the tests @Justin_Barrett. Good to know that deleting record revision history will free up attachment space. Can you tell if it actually deletes the attachment from the server, or is the attachment still publicly available (even if it doesn’t count towards your attachment limit)?

My money is on “No” and I hope I am wrong. If wrong, I would happily pay it forward with a sandwich for those who care to bet in advance of the answer from @Justin_Barrett.

After a quick test, the file still exists. I’ll check again in 24 hours and see if anything changes.

Bill you can’t just use this forum to swindle us into giving you sandwiches all the time

I’m hungry. And it repeats every day.

Just a few comments to the topic

(tl;dr: “it’s still unpredictale and unclear for me”)

Few mothns ago i did automation script to merge attachments from branch to main and hit ‘duplicates issue’(when you merge main’1,2’ with branch’3,4’, you receive ‘1,2,3,4’, but after branch update record(4=>5) it will merge 3,5 to 1-4, and 3 became duplicate. Then I changed it to ‘merge removing duplicates’ and discovered another problem because similar file in two different fields has different links, and defininition “same name=duplicate” is of course wrong. At least, should be name&size

Now i did some utility to backup/restore attachments including small script to display size of all attachments in all tables, and discovered that their actual downloaded number and size less than expected by script (link to attachment contain 8-digit code, which i append to filename for restore purposes, so i supposed 10 similar files must have 10 downloaded “versions”). And it’s not true, Airtable can detect such case and store only one file, with 10 links to it.

But when i tried to test it and uploaded to small table, 3 files repeatedly to 10 records in random order and number per 1 record (by usual upload through user GUI), i found that all of them has different link, none repeated. The method of storing attachments in Airtable is a mystery for me again.

Now i doubt that “Airtable can detect such case”. maybe we just cloned some records with sync or automation ot “horizontal to vertical” table transfer.

Airtable has an internal attachment ID for every attachment that you can see through scripting. Airtable is probably using this internal attachment ID for determining duplicates. Different records could point to the same attachment ID, but you probably cannot use the same attachment ID multiple times in the same record.

The image remains despite being deleted and record history cleared.

Thanks for letting us know. Sounds like Bill was right again. But we’re so used to him being right that no-one was willing risk a sandwich.