Share a link or invite a member: which one you want

Two doors lead out of a database. An invitation makes someone a member — they sign in, hold a role, and see the whole thing. A public view link publishes one saved view, read-only, at a URL that works with no account at all. People reach for the wrong one constantly, usually by inviting someone who only ever needed to look at a list.

This page is the decision. The mechanics of links — making one, what visitors see, the fine print — live in public view links; invitations live in members and roles.

When the link wins

They only need to read. A supplier checking open orders, a client watching a project list, a landlord who wants the bookings calendar. Nobody here edits anything, so nobody needs a role.

They shouldn't need an account. A link opens in any browser, first try, no sign-in, no onboarding email. For someone outside your team, that's the difference between "they looked" and "they meant to."

They should see a slice, not the database. A shared link shows exactly one view: its saved filter, its visible columns, its sort. Records the filter excludes and columns you've hidden never leave the server. Other views, other tables, the member list — invisible. Build a view shaped like what they should see, share that.

You'd rather not count them. Visitors aren't members. They hold no seat and cost nothing, in beta or on any published plan.

When the invitation wins

They need to change anything. A link is read-only with no exceptions — no cell edits, no button presses. The moment someone updates a status, they are an editor.

They need more than one view. A link is one view. Someone who should switch between the board and the grid, open other tables, search, or expand a record to its full panel needs to be inside — even a viewer gets all of that.

You need to know who did what. A link is anonymous by design; Tabla can't tell you who opened it or forwarded it. Members sign in, and their edits are theirs.

The line worth knowing before you pick

An invitation — even at viewer — opens the whole database. Every table, every view, and every field: hiding fields is per-view presentation, not access control, and a member can open any record and see all of it. There is no "invite them to one table" or "hide the salary column from Omar" today; per-field and per-record permissions are on the wishlist.

So the honest rule: if part of the database is none of their business, an invitation is the wrong door, whatever role you pick. The public link is the only mechanism that truly narrows what leaves the server — and it narrows it to one read-only view.

The two doors also compose, and most databases end up using both. The demo plant shop is the usual shape: Laila, Omar and Salma inside as members, running orders and stock — and if a wholesale customer wanted to watch what's in stock, the right move would be a filtered view of the Plants table and one link, not a fourth member. The team edits; the outside world reads a slice.

Taking it back

Both doors close cleanly, from different places:

• A link pauses from the share dialog (turn the switch off — the same URL comes back if you re-enable), or dies for good with Regenerate link, which mints a new token and 404s the old URL immediately.
• A member is removed by an owner from the Share dialog. Access ends immediately; their records stay, stamped as theirs.

Neither takes data with it. Revoking is about the door, never the room.

The questions people ask

Can I send a link that allows editing? No. Links are read-only, full stop. Editing requires a member with an editor role — there's no in-between credential today.

Is the link secret? It's unlisted and marked noindex, and the token is long and random — but anyone who has the URL is in. Treat the link as the credential it is, and regenerate it if it travels too far.

They already have an account — link or invite? Same decision. An account only matters once they're a member; a link neither knows nor cares who's holding it.