Roles and permissions
Who sees what in Nuvailo: admin, manager, employee and client roles, how project scoping works, and how to keep rates and finance data restricted.
Permission questions decide whether people put real numbers into the system. If a supervisor thinks their rates are visible to the whole company, or a client suspects they can see another client project, the data quietly gets worse.
The four roles
| Role | Scope | Typical holder |
|---|---|---|
| Admin | Everything in the company, including billing and user management | Owner, director, finance lead |
| Manager | Assigned projects in full, including their costs | Project or contracts manager |
| Employee | Assigned projects, operational data, no company finance | Site engineer, supervisor, office staff |
| Client | Their own projects only, read-only | The customer paying for the work |
Roles are company-wide, project assignment is per project. A manager is only a manager of the projects they are assigned to.
Project scoping
Assignment is the second half of every permission. Adding someone as a manager does not show them every project, it makes them capable of managing the ones you assign. Removing an assignment removes access immediately, including in the mobile app on next sync.
Finance visibility
Ledger, cash position, salaries and vendor payments are restricted by default. Grant them deliberately, and remember that a person who can see project cost can infer margin.
- Site staff usually need quantities and progress, not rates.
- Managers usually need project cost, not company payroll.
- Only admins should see salaries and company-level cash.
Do not solve a permission problem by sharing an admin login. Shared accounts destroy the audit trail, which is the thing you need most in a dispute.
Client access
A client login is scoped to the projects attached to that client company. They see progress, shared documents and whatever you publish, and never see cost, rates, other clients or internal notes. Turn a client on only after the project data is presentable, because their first impression is the whole point of the portal.
Changing a role safely
- 1
Change the role, not the person
Editing an existing user keeps their history attached to their name. Deleting and recreating breaks the audit trail.
- 2
Deactivate rather than delete leavers
Their past entries stay attributed and valid, and the login stops working immediately.
- 3
Review assignments at project close
Access tends to accumulate. Closing a project is the natural moment to remove it.