Help

This Product Ideas board is currently undergoing updates, but please continue to submit your ideas.

New Field Type: Write Once Field

cancel
Showing results for 
Search instead for 
Did you mean: 
dk82734
7 - App Architect
7 - App Architect

I’ve got a pretty large Airtable base, with multiple tables. The base is synchronized to an external PostgresQL DB. Originally, I used the built-in RECORD_ID() function to keep track of record identity across all tables… but then, I realized that if you ever CLONE the base or RESTORE a base from a previous version, all of those RECORD_ID() values do not stay the same – they become different for each of those records.

Overall, that’s bad when you’re trying to synchronize these records to an external database.

That’s why I use a separate, manually managed, field called “UUID” for all tables. Automation runs such that whenever a new record is created, it will automatically fill in the UUID value (side note: it would be really, really nice if Airtable provided this functionality built-in, but whatever).

In any event, sometimes there are bugs in the Automation, and it might accidentally write a new UUID value into a record that already has a UUID value set. That’s bad.

Therefore, I propose a new Field Type called “Write Once”. It will only allow a value within the field to be set once, and any subsequent overwrites would be denied (either throw an error or silently ignore any future writes to this field). This would solve many, many problems.

What about scenarios where you legitimately want to clone a record that has a UUID value set? Well, in that scenario, all field values would get duplicated (including the “Write Once” field). If that’s not what you want, you could easily write Automation that detects the new, duplicate record (based on CREATED_AT()) and then the automation would 1) create a third copy (with a unique UUID value) and 2) delete the second copy (with the duplicate UUID) – thus, solving this problem.

I’m sure there are many other use-cases for this field type, but to be clear, this “property” should apply to any type of field (e.g., strings, booleans, single-select, multi-select) – enforcing write-once simplifies many, many workflows that honestly require a ton of automation to address this feature gap.