At the start of a project it seems there will be two roles: "admin" and "user". Six months later come managers, accountants, external partners, customers with access to their own data — and permissions start being hard-coded case by case. That is how vulnerabilities and bugs are born. The access model is worth designing up front; it is one of the basic tasks in web application development.
In short: separate two axes — which data a user can access (tenant, organisation, project) and which actions they can perform (role and permissions). Check permissions on the server for every request and log important actions.
Multi-tenancy: whose data is it
If different companies use the product, each one's data must be isolated. The main approaches:
| Approach | How it works | When it fits |
|---|---|---|
| Shared database with tenant ID | Every record carries the organisation ID | Most SaaS, fast start |
| Schema per tenant | A separate set of tables per customer | Stronger isolation needs |
| Database per tenant | Full isolation | Large customers, regulatory requirements |
Permission models
- RBAC (role-based): roles with sets of permissions — owner, admin, manager, viewer. Simple and clear.
- Resource permissions: view, create, edit, delete per section — more flexible, ideal for CRMs and back offices.
- Attribute-based rules (ABAC): access depends on properties — "a manager sees only their own deals". Powerful but harder to maintain.
What to build in from day one
- An organisation ID in every business table.
- Server-side permission checks, not just hidden buttons in the UI.
- User invitations with a role and an expiring link.
- An audit log: who changed what and when.
- Separate permissions for data export and deletion.
Common mistakes
- Permissions checked only on the frontend — the API is open to any signed-in user.
- Sequential record IDs not checked for organisation ownership.
- Roles hard-coded with no way to configure them.
- No action log — incidents cannot be investigated.
Frequently asked questions
Can multi-tenancy be added later?
Yes, but at a cost: data migration and rewritten queries. If the product will serve several companies, build it in from the start.
Do I need single sign-on (SSO)?
Often for enterprise customers, but it can wait in the MVP. See our article on SaaS MVP priorities.
How does this relate to CRM?
Resource permissions are the backbone of any CRM: managers see their deals, heads see the department. We use the same model in CRM/ERP systems and connect data from other services via APIs.
Designing a product with roles and customer portals? Send a request on the web applications page and we will design the data, access and audit model before development starts.