When a user wants to add info to a client record, they should first search for that client. I am afraid that they will skip the search and create the client record, resulting in a duplicate record. I want to prevent this.
The best way would be to be able to define a primary key, and Tape validating a new record against this key. Today, it is possible to define a field to be required, but not to be unique. Having a unique key for a record would be perfect (and actually, quite normal for a database system to have).
The second best way would be to have a validation trigger at field level. It should fire when a field value is entered, and must be able to alert the user. This cannot be done with an automatoon on the event when a record is created, because it fires after the record is created, ánd is not able to present an alert to the user.
This would definitely be a fantastic extension of Tapes’ functionality!
Having a primary key would be awesome! I have a use case for this right now as well.
I have a networking directory. The primary key would help stop duplicate profiles from being created.
…
New records process calculations in real time, before saving. I wonder if a workaround could be running a comparison on a few fields and optionally displaying a validation message above the submit button?
Tested this out, and wanted to share what I found for anyone else considering this.
With a little help from Claude, this is my conclusion regarding the workaround you suggested.
The “calculations run live before saving” part is real, it’s a feature of the New Record Experience beta. But it doesn’t help for duplicate checking across a table.
Two hard limits, confirmed in the calculation field docs:
A calculation field can only read fields on the current record, plus fields reachable through an existing relation. A new record has no relation yet to other unrelated records in the same app, so there’s no way to reach “all other Clients” from inside the field.
Async JavaScript (Promises, setTimeout, etc.) isn’t supported inside calculation fields. So even if you could reach another table, you couldn’t call something like getManyFiltered, that function belongs to the Execute Script step in automations, a separate execution environment with its own library set.
So a calculation field can’t do a live duplicate check against the whole table, by design, not a bug or workaround-away limitation.
What does work: an automation on After Create, with an Execute Script step. That context supports async and getManyFiltered, so you can search existing records, run your own comparison logic, and flag likely duplicates (e.g. a Status field set to “possible duplicate”) for someone to review. Not a real-time block, but a reliable check right after the record is saved.
So, a real primary key functionality is the road to take. Do you have votes left for this one?