Problem
The current single-workspace model is a good fit for mutually trusted teams, but some self-hosted deployments need a small server-side access boundary between sales representatives.
Today record owners are useful filters and attribution, while accepted workspace members share the CRM data surface. A practical baseline would let an administrator opt into owner-scoped access without turning the project into a multi-tenant authorization platform.
Proposed minimum
- Preserve the current workspace-wide behavior as the default for existing installs.
- Add an optional server-side access policy:
- workspace
owner and admin roles can read and manage all CRM records;
- ordinary
member users can read and manage records they own;
- the policy for unassigned records is explicit and defaults safely.
- Apply the policy consistently to companies, contacts, deals, activities and related email/calendar history.
- Enforce it in list, by-id, mutation, search, dashboard, bulk-operation and agent-tool paths—not only in UI controls.
- Ensure scheduled agents and background jobs use an explicit service/effective principal rather than accidentally inheriting workspace-wide human access.
- Add table-driven tests for cross-owner reads, IDOR attempts, mutations, search, aggregates and agent tools.
Non-goals
- Multi-tenancy.
- Field-level permissions.
- A complex enterprise role builder.
- Hardcoded organization-specific reporting hierarchies.
Would the maintainers be open to a small central policy interface (for example, a record-access resolver that supplies scoped Prisma predicates) with the current shared-workspace behavior as its default implementation? This would let self-hosters add basic owner/admin access control without forking every data surface independently.
Problem
The current single-workspace model is a good fit for mutually trusted teams, but some self-hosted deployments need a small server-side access boundary between sales representatives.
Today record owners are useful filters and attribution, while accepted workspace members share the CRM data surface. A practical baseline would let an administrator opt into owner-scoped access without turning the project into a multi-tenant authorization platform.
Proposed minimum
ownerandadminroles can read and manage all CRM records;memberusers can read and manage records they own;Non-goals
Would the maintainers be open to a small central policy interface (for example, a record-access resolver that supplies scoped Prisma predicates) with the current shared-workspace behavior as its default implementation? This would let self-hosters add basic owner/admin access control without forking every data surface independently.