Record Lock

A record lock ties a table's records to the person named in one of its User fields. Instead of "everyone in the workspace sees this whole table", each member gets their own slice of it.

Two modes:

• See only their own records — a member only sees records assigned to them. Everyone else's records simply aren't there: not in the grid, not in search, not in exports, not by direct link.
• See all, but edit only their own — everyone sees every record as usual, but a member can only change the records assigned to them. Someone else's record opens read-only, exactly like it would for a Read Only member: no Save button, nothing to type into.

Typical uses: a Leads table where each rep works only their own leads, a Requests table where anyone can browse but only the assignee can update, or an HR table where a manager sees only their own reports.

Setting it up

1. Give the table a User field — the person who "owns" each record. Leave Allow Multiple off.
2. Open the table's Configure screen, go to the Fields tab, and click that User field.
3. In its settings, set Record Lock to one of the two modes.
4. Save.

The setting lives on the field itself, alongside its other options — the same place you set Admin Only or Required.

Only one field per table can lock records, and a field that allows multiple users can't (the option is hidden for those).

To remove the lock, set Record Lock back to Off and save.

Who the lock applies to

Two things follow from this that are worth knowing before you turn it on.

Admins are never locked out. They see and edit every record, and they're the only people who can reassign one. This is deliberate — otherwise a table could end up with records nobody can reach.

Automations keep working normally. A flow isn't a person, so it isn't restricted. Rules like "when a lead goes stale, reassign it" run exactly as before. The same goes for PHPScript and imports.

The owner field becomes read-only

Once a table is locked, ordinary members can't change the field the lock uses — it's shown with a lock icon, like an admin-only field.

• New records are assigned to whoever creates them, automatically — the field is pre-filled with your name on the new-record form.
• Reassigning a record is an admin action.

That's what makes the lock meaningful: if members could edit the field, they could hand records to each other — or, under "see only their own", make their own record disappear.

Records with nobody assigned

Under See only their own records, a record whose User field is empty is visible to admins only. No owner means it isn't anybody's record.

This matters when you lock an existing table: any record that doesn't already have that field filled in drops out of view for everyone but admins. Fill the field in first — the grid's Edit Selected bulk action makes short work of it — or expect to assign the leftovers afterwards.

What a lock doesn't cover

A few places still show data from a locked table. None of them expose a record to someone outside the workspace, but they're worth knowing about:

• Reports count and total every record in the table, not just yours.
• Workspace activity can show changes to records you can't open. The Activity tab on an individual record is restricted normally — but once a record is deleted, its history stays readable to admins only, even by the member who owned it.
• Lookup fields pointing at a locked table show the record title they're linked to, even if you couldn't open that record directly. The picker for choosing a new one only offers your own records.
• Workspace export includes every record — it's an admin action, and admins see everything anyway.
• Public API keys created at the account level act as the account owner, so they aren't restricted. A personal API key acts as you, and is.

If you need a table where none of that leaks, keep the sensitive data in a separate table rather than relying on the lock alone.

Embeds and calendar feeds

A table set to See only their own records can't be published as an embed or an iCal feed. Both are viewed by people who aren't signed in, so they can never match a lock — the feed would just be empty. Those options are disabled on the Public tab while the lock is set.

Web forms are unaffected: they only create records, they don't display them.

Record Lock vs. other tools

Views are not a security boundary: any member can change a view's filters or ignore it. A record lock is enforced on the server on every read and every write.