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:

• Read — 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.
• Write — everyone sees every record as usual, but a member can only change the records assigned to them. Someone else's record is read-only.

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. It must allow a single user, not multiple.
2. Open the table's Configure screen and go to the General tab.
3. Under Record Lock, pick that field and choose Read or Write.
4. Save.

If the table has no single-user field, the Record Lock option doesn't appear — add the field first.

To remove the lock, set the picker back to Not locked 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.
• 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 a Read lock, make their own record disappear.

Records with nobody assigned

Under a Read lock, 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.
• 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 read-locked table 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.