So, forms just 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 an email field 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.
As you cannot create an Airtable account without having to activate your account from the inbox from the email address you’ve used for that sign-in, you cannot impersonate the person and his/hers email address in the record they want to change. (what a sentence… I hope this makes sense) The other way is to login with the email address from the record, but then you’ll obviously need a correct password.
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
create a new table with the fields from your client table you want them to be able to upgrade + 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.
Edit: another great find; if you try to create an account on someone else’s name and email to try and change their data, you cannot send the form without confirming your new account. This ofcourse has to happen from inbox from the email you’ve -wrongly- used.