System Manual
Security & Multi-tenancy
Every customer has its own isolated workspace. Access is set by roles and per-module permissions, and approvals and signatures are recorded with who made them.
Isolated workspaces
Each customer is an isolated workspace, or tenant. Data is scoped per tenant with row-level security, so one workspace cannot see another's records. One person can belong to more than one workspace and switch between them, which lets consultants and multi-site teams use one account without mixing data.
Roles and per-module permissions
Access is controlled by roles combined with per-user, per-module permissions. You can give one person access to individual modules, including a read-only "view" level for people who need to see a module but not change it.
A permission gate checks these rules in the interface and again on the server. The interface hides what a user cannot access, and the server checks the same rules on its own.
The accounts layer
For organizations that run several workspaces, for example one per site or business unit, an accounts layer groups the workspaces they own.
Activity log and sign-in
Administrative actions and approvals are written to an activity log that records who did what. People sign in with an email address and a password.
| Tenant model | Isolated workspace per customer |
| Data isolation | Row-level security, scoped per tenant |
| Multi-workspace | A user can belong to several, with a workspace switcher |
| Access control | Roles and per-user, per-module permissions, including view-only |
| Enforcement | Permission gate in the UI and on the server |
| Above workspaces | Accounts layer for organizations running several |
| Activity log | Administrative actions and approvals logged |
| Sign-in | Email and password |
People make the decisions
Routine work is recorded as it happens. Actions that commit the organization, such as approvals and signatures, need the right permission, are made by a person, and are recorded with who made them and when.