Here are some ways to let external users update your Airtable data:
Airtable Interface
Create an Airtable interface and add users as interface-only collaborators.
Pros:
You can customize the experience completely within Airtable.
You get detailed record history that includes the actual person who made the change.
Users can edit any field type
Users can see formula results
Easiest system to maintain
Cons:
You have to pay for each external user. This can be the most expensive option.
The external users know that you are using Airtable.
The ability to style the data is very limited.
Users must log in to edit data
Airtable Prefilled Forms + Automations
Set up a formula field that generate the url for a prefilled form that identifies the record you want to update and how you want it updated. Send this url to your users. When the form is submitted, have an automation that finds the original record and performs the update.
Pros:
This can be free (not including your Airtable subscription fees).
Users do not need log in to submit updates
Cons:
Record history does not show who actually made the edits
The user experience can be very clunky.
Users cannot see formula results
The link for the prefilled url can contain obsolete data.
Limited ability to update attachment fields and long text fields
3rd Party Portal Systems
Use a third party system to create “portal access” to your data.
Pros:
There are many portal systems available at different price points
You typically pay a flat monthly fee instead of a per user rate.
Far more styling options to make your portal pretty.
You can control if you want to require users to log in or allow anonymous edits.
You can set the domain name for the website of the portal.
Users can edit any field type, including attachments, rich text fields, etc.
Cons:
Monthly third party fees can be expensive
Record history does not show who actually made the edits
Limited ability to see formula results or possible side-effects when viewing formula results
3rd Party Integration Service w/ Webhook
Use a third party integration service capable of receiving a webhook and updating Airtable records. When the service receives the webhook, have it update the Airtable record. In Airtable, create a formula field that combines the webhook url with information identifying the record. Send this url to your users.
Pros:
Users do not need to log in.
Can be more much more affordable than third party portal systems
Cons:
There is no “confirmation” stage. Accidental clicks can update record data prematurely with no undo.
Airtable record history will not state who updated the record.
The link for the webhook can contain obsolete data.
Will typically open a browser window when the link is clicked, although you can adjust the styling of what shows in the browser window.
User cannot customize updates at all–the specific data changes must be hardcoded into either the formula field for creating the url or hardcoded into the third party integration system.
Another way to let external user update their data for free
Forms got the option “Collect respondent email addresses automatically (sign-in required)”.
When this option is checked and people open the form URL, they will be prompted to sign in with Airtable or make an account. After that, they can fill in the form and the email address they used to sign in or to create a new account with, will be stored in a auto created “created by” field in your table.
This opens up the possibility to let people change their data, using their email address as a unique identifier. When a record, let’s say a client record, contains an email address, you can crosscheck this with the auto filled in email address in the “created by” field mentioned above, by prefilling and hiding it in the form. Via automations you can access the underlying email address from the “created by” field and check it against the one in the existing record.
Use case
I’ve build a digital directory with some 800 members. Via a shared gallery view, everyone can click a button (field) “change my personal data” that opens a form with their current email address prefilled and hidden. They click the URL, have to sign-in or create an account with the email address that is mentioned in their record (this is mentioned in the form info). After they fill in the form, a formula checks every new entry. Is the email address in the “created by” field the same as the email address in the record they want to change?
Yes = update record via triggered automation
No = they get an email (via the address in the “created by” field) saying the email address didn’t match the one in te record they want to change, via a triggered automation
How to
create a new table with the fields from your client table you want them to be able to update + an email field + an record_id field (single line text)
create a form with those fields prefilled + the email and record_id field prefilled and hidden + with the new option checked + mention in the form info that the email to sign-in/create an account with, has to match the one in their record
create a button field with a prefilled form URL in the client table, using the form URL in your new table
client clicks on button in shared view and has to sign-in or create an account
input comes into new table
automation 1 takes the email address behind the auto filled in “created by” field and updates the email field
a formula field checks IF() the now filled in email field is not empty and compares it with the current clients email that (prefilled and hidden) came along with the form; if both emails are the same = “OK”, if not = “NOK”
if the formula field is not empty (and thus the first automation worked), automation 2 is triggered that looks up the client record in the client table, based on the record ID that came along with the form. If (conditional group) a record is found (length of your “find record step” > 1) AND the formula fields says “OK”, it updates the client record (and maybe puts a checkmark in a control field). If not, you can make the automation send an email to that person via the email from the “created by” field.
It’s far from a real portal, but it is imo the best option/workaround so far to letting external user (so no access to the base) change data for free.
This is a wonderful variation on the prefilled form technique that doesn’t actually require a prefill, although I still think that prefilling is useful and can be used in conjunction with this method. Your method also lets you capture who submitted the change and when.
Wow!! @Kuovonne, thank you for the comprehensive list! And @Databaser, thank you for the detailed instructions!
To add onto the great information already posted above, I wanted to let people know about how to trigger an external webhook WITHOUT opening up a browser window.
I’ve created a separate post on that topic here:
While this method is good for triggering a webhook from within Airtable without opening a web browser, that technique isn’t the best for external users, since it requires a scripting automation. Once you have a scripting automation, you might as well have the scripting automation take care the entire record update.
Totally agree! I was mostly considering people like myself who don’t know how to script. The script I included in that other post is pretty much the extent of my scripting knowledge.
After that, I can use Make for everything else.
Although I should note that even for people who know scripting, integrating with external apps is often easier for them with a low-code visual building tool like Make.
I should have clarified–once you are in an Airtable automation, you can use the automation to update the original record, using a combination of the “Find Record” and “Update Record” actions, OR using a script.
Absolutely. But we should take that to another topic. I use both scripting and Make extensively. And when I use Make with Airtable, it currently is almost always in combination with an Airtable script.
And 
