Govern access with roles, projects & modules
Design access the clean way — set an organization-wide role baseline, adjust per project only where needed, scope module access, and rely on consistent enforcement.
Access in TraceUnified isn’t a single switch — it’s a few layers that resolve together: an organization-wide role, adjusted by the project, scoped to the modules in play, and enforced at every action. This guide walks designing that access so it stays explainable rather than buried in one-off grants. For the model itself, see Access rules.
Start from the role baseline
A role sets the organization-wide baseline — the access level and enforced permissions a holder carries everywhere. Get this right and the common case is covered by role alone.
Before you start Your roles should already be defined — see Set up users, roles & permissions.
- For each role, set its access level and enforced permissions — the baseline that applies wherever the role is held.
- Assign people the role that matches their function, so most of their access is explained by one thing.
Result The majority of access is governed by roles you can point at and explain. See Roles & permissions.
Adjust per project only where needed
Project permissions adjust the baseline for a specific project — the place to handle a genuine exception without rewriting the role.
- Where a project needs to differ, use project permissions to narrow or widen the role baseline for that project only.
- Reserve this for real exceptions rather than making it the default path — every override is something you'll later have to explain.
Result Project-specific needs are met without diluting the org-wide roles. See Project permissions.
Scope module access
Module access determines which modules a project uses and the default access to each, so a user’s effective access is scoped to the modules actually in play.
- Set which modules the project uses and the default access to each.
- Confirm the resolved picture: the role, adjusted by the project, scoped to these modules, is the access each person actually has.
Result Access is correct all the way down to the module. See Module access.
Note The discipline that keeps access governable is simple: lean on roles for the common case, and reserve project permissions and module access for deliberate exceptions. Access you can explain by pointing at a role and a short list of overrides stays trustworthy; access scattered across one-off grants does not. Enforcement is consistent either way — a user simply cannot take an action their resolved access doesn't permit.
Where to go next
The full enforcement model — how the layers combine for any user and action — is in Access rules. To oversee who is acting on a record right now, rather than who may, see Lock management.