Security & trust

Access is decided by the database, not the interface.

Every read and write is checked in Postgres with row-level security, so what a person can see does not depend on a screen hiding it. A published form, an app, the REST API and the grid all pass through the same policies.

Enforced in the database

Access is checked in Postgres with row-level security — below the UI. Hiding a column in the client is never what protects it; the database decides what each request can read or write.

Sheet, row & column access

Grant access to a whole sheet, specific rows, or specific columns — to individual people or to groups — so everyone sees exactly the slice of data they should.

Conditional, attribute-based rules

Go beyond static lists: grant access based on a cell's value — for example, only rows where Region matches a user's region — evaluated per request.

Audit trail

A tamper-evident activity log records who changed what and when, so you can review history and answer 'who touched this record?'

Modern authentication

Your data stays portable

Export any view to CSV, Excel, or JSON at any time. Your data is yours — there is no lock-in, and the API lets you move it programmatically.

Infrastructure.

Relationsheet runs on managed cloud infrastructure: a Postgres database with row-level security for tenant isolation, served over HTTPS. Secrets stay on the server — only data you explicitly publish, such as a public form or a shared view, is ever exposed, and even then through the same policies rather than around them.

What we do not have.

No SOC 2, ISO 27001 or HIPAA attestation. We are not going to imply one with a badge.
No enterprise SSO or SAML. Sign-in is email or Google.
No customer-managed encryption keys and no single-tenant deployment.
If your procurement needs any of these, tell us what and by when — that is more useful to us than a roadmap page is to you.

Questions about permissions or hosting?

We are happy to walk through exactly how access is enforced for your team.