Require unique values

Some values are only useful if no two records share one: an SKU, an order number, an email that identifies a customer. Require unique values is the switch for that, offered while you're adding a field. It isn't an app-side check that a clever import could slip past — it becomes a real unique index in the Postgres table underneath, and Postgres itself refuses the duplicate. Two people saving the same value in the same instant can't both win.

Which fields can have it

The plain, typed, single-value types: single line text, email, phone, web address, number, currency, percent, date, and single select.

Everything else can't, each for a plain reason: long text is prose, not a key; a checkbox has two possible values; multi-select, member, link and attachment cells hold lists; and computed fields — formula, lookup, rollup — would put a rule on a value nobody types, so nobody could fix a violation.

Set at creation, and only then

The switch appears while adding a field and not after, which also answers the awkward question of existing duplicates: a brand-new field has no values yet, so the rule can never start out already broken. There is no "turn it on later and fight about what's already there."

That cuts both ways — an existing field can't gain or lose the rule. Over the API, an update that sends "unique": true for an existing field is quietly ignored rather than half-applied. To get uniqueness onto data you already have: add a new unique field, paste the column in (duplicates will refuse right there, which is the point), then delete the old field.

Empty cells never collide — the rule is about values, and many records can lack one.

What a violation looks like

Every write path hits the same wall: typing in the grid, pasting, imports, and the API. The whole write is refused — a batch of 100 records with one duplicate lands zero records, all-or-nothing — and the error names the field and the clashing value. Verbatim, from a real attempt:

{
  "error": {
    "code": "bad_request",
    "message": "\"SKU\" must be unique — \"PLNT-001\" already exists."
  }
}

HTTP 400, like any refused write — see /guides/api-errors-and-limits.

One subtlety, decided in favor of the living: a record in the trash doesn't block its value from being reused. The flip side: if the value has been reused, restoring the trashed record fails — the rule holds at the moment of restore, and today the error is a bare "Something went wrong" rather than one that names the clash. Delete or change the living duplicate, then restore.

What to use it for — and not

Good: identifiers. SKUs, invoice numbers, membership codes, one-row-per-email tables that an upsert merges on.

Less good: making a name field unique because duplicates feel untidy. Two customers genuinely named Mona Adel will eventually exist, and the field will refuse the second one. Uniqueness is for values that identify, not values that describe — a display field doesn't need to be unique to do its job.