Share one table, not your workspace

There's a moment in every client project where someone outside the team needs to see the data. The catalogue needs sign-off, the auditor wants the transactions, the client wants to correct their own product descriptions. The usual options are all bad: export a CSV that's stale by Friday, screen-share a spreadsheet, or provision a full account for someone who needs one table for two weeks.

Guest links are the missing option: a URL that opens one view, live, for someone with no account at all.

What a guest actually gets

• Exactly the view you shared. Not the workspace, not the other tables, not the schema — as far as the guest can tell, the rest doesn't exist. The view's own filters apply, so "Orders — 2026, region EU" shares precisely that slice.
• Read or edit — your choice per link. An editing guest works in the same live grid your team uses, with the same validation rules enforced. A guest can't enter bad data any more than a member can.
• Live, not a snapshot. Changes your team makes appear to the guest in real time, and vice versa. The Friday-stale export problem disappears because there is no export.

What you keep

• A time limit. Links expire when you say — the access for the two-week audit ends itself.
• A kill switch. Revoke a link and it stops working, immediately.
• The boundary. Guests never see member lists, other views, or settings. There's no privilege to escalate because there's no account to escalate.

For agencies this is quietly the whole client-delivery story: the client's data lives in the client's database, your team manages it in SchemaStack, and the client watches or edits their slice through a link — no seats bought, no data hosted on your side, nothing for their IT to object to.

What it doesn't do (yet)

• The link is the credential. Anyone holding it has the access it grants — treat it like a password, share it over a channel you trust, and lean on expiry + revocation. There's no per-guest identity or "which guest edited this" attribution.
• Access is per view, not per row — a guest sees every row the view shows. If you need each external user restricted to their own rows, that's a different feature: external identity providers with row-level security.
• No branding or custom domains on the guest page — it looks like SchemaStack, because it is.
• Guests use the interface, not the API — API access needs a key or a token.

The guest access docs cover creating, scoping and revoking links in detail.