Multi-tenancy, roles, sessions and traceability
Security and data isolation
A professional practice's data is third-party data. Xedul's security model starts from that premise: isolation isn't an interface feature, it's a property of the database.
Isolation per organisation
Xedul is multi-tenant by construction. Every row of every work table carries the organisation it belongs to, and row-level security policies enforce the boundary directly in PostgreSQL.
The difference from a filter applied in application code is substantial: if the filter lives in the code, a mistake in one query bypasses it. If it lives in the database, the query simply returns no rows from other organisations.
Authentication
Authentication is handled by Supabase Auth, with token-based sessions and automatic refresh. Sign-in uses email and password; inviting a new user triggers a password-setup flow that doesn't require transmitting credentials.
Authorisation
Above authentication sits role-based access control, described in Users and permissions:
- Admin — organisation governance and full access to the work.
- User — daily work, without governance of settings.
- External user — visibility restricted to linked entities only.
Email integration sessions
The Gmail and Outlook integrations maintain their own Xedul session, separate from the web application's cookies.
In the Chrome extension, access and refresh tokens are held in the extension's local storage; the script running inside the Gmail page neither reads nor stores them, because authentication and API calls go through the service worker.
In the Workspace add-on, tokens live in the script's user properties. The authorisation used to read attachments from Gmail is server-side only: it is never returned to the browser, and it is removed from the draft once import completes.
This separation is deliberate. A compromised integration token is not equivalent to an application session, and vice versa.
Document storage
Uploaded files reside in managed storage, with checks on permitted types. Files of a disallowed type are rejected at upload, including automatic imports from email attachments.
Traceability
Actions on work entities leave a trace. It serves to reconstruct what happened on a case — useful in handovers — and to answer a client asking when a given piece of work was carried out.
For traceability to be worth anything, each person must have their own user: a shared account makes every trace unusable.
Production protection
The project applies specific measures to the production environment, including validating environment variables before build, automatic backup before schema changes, and a release strategy that validates the deployment before applying database changes.
The practice's responsibilities
Some things remain with whoever uses the product:
- One user per person, never shared accounts.
- Periodic access review, particularly of external users no longer active.
- The minimum sufficient role when a new person joins.
- Few admins: the role is for governance, not daily work.
- Verify external access with a test account before enabling it.