Skip to content

Guest Access ​

Guest access lets you share specific views with external users — clients, contractors, auditors, or the public — without requiring them to join your organization.

Why View-Level Access ​

Guests only see the specific view you share, not the entire workspace. They can't see your entity schema, other views, or workspace structure. This follows the principle of least privilege:

Workspace: "Marketing Analytics"
├── View: "Campaign Performance"   (internal only)
├── View: "Budget Overview"         (internal only)
└── View: "Client Report"           ← guest sees only this

Use Cases ​

Client Reporting ​

A marketing agency builds an analytics workspace. The client gets read-only access to a "Client Report" view — they see their data without seeing internal dashboards.

Contractor Access ​

A freelance developer needs access to a "Design System" view for a 3-month project. Access is time-limited and scoped to that one view.

Partner Collaboration ​

Two organizations co-developing a product. Users from one org get editor access to a shared view in the other org's workspace, without becoming full members.

External Audit ​

An auditor reviews compliance records through a time-limited, read-only view. No permanent org membership needed.

Public Data ​

A government agency publishes open datasets. Anyone can access the view via a public link — no authentication required.

Customer Self-Service ​

A SaaS company gives each customer their own analytics view. Customers access their specific view without seeing internal data.

How it works ​

Each guest gets a link backed by a unique access token. The token is single-use-friendly to share but unguessable, and only the hash is stored — the plaintext is shown once when the link is created and never again.

Each link is scoped to one view. There is no "guest in a workspace" concept; a guest is always a guest of a specific view.

Roles ​

A guest link has one of two roles:

  • GUEST_VIEWER — read-only. Can open the view, read rows, run filters, export if the view itself is exportable.
  • GUEST_EDITOR — read + write. Can edit cells, add rows, and delete rows, subject to the view's own settings (see below).

There is no "create permission" or "export permission" as a separate toggle. The view's editable, addable, and exportable flags are the source of truth; the guest's role just determines whether they're allowed to use those capabilities.

Limits and expiration ​

Each link can have:

  • An expiration timestamp (expiresAt) — after this moment the link stops working.
  • A maximum-use count (maxUses) — the link's currentUses counter increments on each access; once it hits the limit, the link stops working.

Either, both, or neither can be set. A link with no expiration and no max-uses works until it's revoked.

Revocation ​

Any workspace admin can revoke a link at any time from the view's permissions panel. Revocation is recorded with revokedAt and revokedBy; the link is rejected on subsequent access. Revocation is instant — there's no grace period and no token re-issuance.

Real-time updates ​

Guest-link creation and revocation broadcast as SSE events to all connected workspace members (view.guest.created, view.guest.revoked), so a teammate revoking a link is reflected in everyone else's UI immediately.

Permission resolution ​

When a guest hits a view, both the role and the view settings apply. The view always wins on capability gates:

View settingGuest roleResult
editable: trueGUEST_VIEWERRead-only (role wins)
editable: trueGUEST_EDITORCan edit
editable: falseGUEST_EDITORRead-only (view setting wins)
addable: trueGUEST_EDITORCan add rows
addable: falseGUEST_EDITORCannot add rows
exportable: trueGUEST_VIEWERCan export
exportable: falseanyCannot export

In short: the role grants intent ("can edit"); the view grants capability ("editing is enabled here"). Both must agree.

What guests cannot see ​

A guest only sees the one view their link is scoped to. They cannot see:

  • The workspace's other views
  • The entity schema (column metadata, constraints, relationships)
  • Other guest links on this view or any other view
  • Workspace members or organisation structure
  • Any audit log

Workspace admins create links from the view's permissions panel:

  1. Open the view's Permissions panel
  2. Click Add guest link
  3. Choose role: GUEST_VIEWER or GUEST_EDITOR
  4. Optionally: name, email (both for your own tracking), expiration, max-uses
  5. The plaintext token is shown once — copy it before closing the dialog. The link can be regenerated by revoking and creating a new one if the original is lost.

SchemaStack Documentation