Permissions and access control
Screen reference
EVX Software uses a layered permission model. A user's final access is determined by their Role, direct User Permissions, Groups, Module Permissions, and access to each relevant Dimension such as Clients, Projects, Workspaces, Sites, or Services.
This page explains how EVX Software permissions work, including role ceilings, default permissions, group inheritance, dimension access, and object-level access.
Permission layers
| Layer | What it controls | Key rule |
|---|---|---|
| Role | The maximum permissions the user can ever receive | A Role is the permission ceiling. |
| Role Default Permissions | The permissions loaded automatically when a new user is created with that Role | Defaults affect new users only. |
| User Permissions | Permissions assigned directly to one user | Can grant permissions only within the Role maximum. |
| Groups | Shared permissions assigned to multiple users | Group access is combined with user access, but still capped by the Role. |
| Module Permissions | Which modules/tabs are available to the user | Modules have defaults, not maximums. |
| Dimension Permissions | Which Clients, Projects, Workspaces, Sites, Services, etc. the user can access | To access an object, the user must have access to all relevant dimension members assigned to it. |
| Object permissions | What the user can do with records: read, write, delete, etc. | Object access depends on both permissions and classification. |
Where permissions are configured
Administrators configure permissions from Settings → Users, Groups and Permissions.
The main areas are:
- Users: create users and set individual permissions.
- Groups: define reusable permission sets for teams or departments.
- Roles: define default permissions for each role and the maximum permissions available to each role.
- Module Permissions: decide which tabs/modules users can access.
- Dimension Permissions: grant access to Clients, Projects, Workspaces, and other dimension members.
- Permissions for objects without classification: define access to objects that are not assigned to a dimension member.
Default permissions vs maximum permissions
Every Role has two related permission sets:
| Concept | Meaning | Can administrators change it? | Who it affects |
|---|---|---|---|
| Default Permissions | Permissions automatically loaded when a new user is created with that Role | Yes | New users created after the default is changed |
| Maximum Permissions | The highest access that Role can ever receive | No, not from normal user/group permission assignment | All users with that Role |
A permission can only become active when it is allowed by the user's Role Maximum. If the Role Maximum does not allow it, the permission appears unavailable/greyed out and cannot be granted directly or through a Group.
Example: off by default, but allowed by maximum
An Executive may not receive security configuration rights by default. If that permission is within the Executive maximum, an administrator may enable it later for a specific user or through a Group.
Example: blocked by maximum
A Guest cannot be turned into a full editor just by adding the user to a Group with broad permissions. If the Guest Role maximum does not allow editing or uploading, those permissions remain unavailable.
System permissions
System permissions control actions that are not limited to one Project or Client, such as managing users, managing templates, seeing other users' time entries, or changing billing settings.
Module permissions
Module permissions control which modules/tabs a user can access.
Modules are different from system permissions because modules have default module access, but they do not have a separate Maximum setting in the same way system/object permissions do.
Client and project permissions
Client and Project permissions define which client/project records the user can access and what level of access they have.
Administrators can move items between With permissions in and Without permissions in, and can configure access for a client, project, folder, or descendant records.
Useful actions include:
- Clicking a permission column such as Read & Write to select that level quickly.
- Applying the selected permissions to all clients/projects below a specific hierarchy point.
- Applying the selected permissions to all clients/projects.
Workspace permissions
Workspace permissions work similarly to Client and Project permissions.
Permissions for objects without classification
Some objects may not be classified under a Client, Project, Workspace, Site, or other dimension member. EVX Software treats these as a special case.
Typical permission levels are:
| Permission level | Meaning |
|---|---|
| None | No access. |
| Read only | Can view and comment where comments are allowed. For tasks, this may include completing tasks assigned to the user. |
| Read & Write | Can view, create, and modify existing objects. |
| Read, Write & Delete | Can view, create, edit, and delete objects. |
Group permissions
Groups let administrators assign permissions to multiple users at once.
A Group can include:
- Users.
- System permissions.
- Module permissions.
- Client and Project permissions.
- Workspace and dimension permissions.
A user may belong to multiple Groups. The final permission set is the union of direct User Permissions and Group Permissions, but the Role Maximum still applies.
How final access is calculated
Role Maximum
↓
Role Default Permissions
↓
Direct User Permissions
↓
Group Permissions
↓
Dimension Permissions
↓
Effective Access
For system and module permissions, EVX Software uses OR logic: if any allowed source grants the permission, the user receives it. For dimension access, EVX Software uses a more restrictive model: users must have access to every relevant dimension member assigned to the object.
Troubleshooting access issues
When a user cannot access an object, check these items in order:
| Step | Check |
|---|---|
| 1 | Is the user's Role allowed to receive the permission? |
| 2 | Was the permission turned on for the user or one of the user's Groups? |
| 3 | Is the module enabled for the user? |
| 4 | Does the user have access to the Client, Project, Workspace, Site, Service, or other dimension member assigned to the object? |
| 5 | Is the object unclassified and therefore controlled by object-without-classification permissions? |
| 6 | Are there multiple dimensions assigned to the object, and is one of them blocking access? |
Detailed role defaults and maximums
The following companion page contains the detailed matrices for each Role:
- System permission defaults and maximums.
- Module permission defaults.
- Object permission defaults and maximums.
- Additional module permissions such as billing/cost access and completed payment editing.