GENECRM seals every workspace's data off with Postgres row-level security, so one tenant can never read another's rows. That isolation is the foundation the rest of the security model — SSO, roles, audit logs — stands on.
When you run many customers on one platform, the most important promise you make is also the simplest to state: one tenant can never see another's data. Everything else — SSO, roles, audit logs — builds on top of that promise.
How does row-level security isolate tenants?
GENECRM enforces isolation with Postgres row-level security (RLS). Every row
carries a tenant_id, and every query runs in a session pinned to the caller's
tenant. The database itself refuses to return another tenant's rows — so isolation
doesn't depend on every developer remembering to add a WHERE tenant_id = … clause.
That's the difference between "we're careful" and "the system won't let it happen."
What sits on top
- SSO (SAML / OIDC) & SCIM so identity stays with your IdP.
- Granular roles from viewer through owner, plus operator and tenant-admin consoles.
- An audit log of every meaningful change — who, what, when, and to which record.
- GDPR export & deletion as a button, not a project.
These are present from the first workspace, not gated behind a future "enterprise" upgrade — because a security review shouldn't be the thing that stalls a rollout.
Bring it to your team. Read the security overview or start free.