Permissions and Roles
Kazinex Workflows uses a two-layer access model: a project role that broadly defines what a user can do, and access control groups that add fine-grained permission and document visibility filters on top. Every user on a project must have a role; access control group membership is optional.
Project roles
Six roles are available. Each user has exactly one role per project (they may have different roles across different projects).
| Role | Level | Description |
|---|---|---|
| Org Admin | Organisation | Full access to all projects and organisation-level settings. Can create/delete projects, manage all users and templates, and change any setting. |
| Project Admin | Project | Configures project settings, templates, review matrix, packages, and reviewer groups. Can invite and manage project-level members. |
| Document Controller | Project | Operates the register, uploads documents, issues transmittals and correspondence, starts and manages workflows, creates guest shares. The primary day-to-day operator role. |
| Reviewer | Project | Responds to assigned workflow steps (review, approve, acknowledge, sign). Can view the register and reports. Cannot upload documents or issue transmittals. |
| Approver | Project | Same as Reviewer. The distinction is semantic — use Approver for users who hold formal sign-off authority. Both roles have the same technical capabilities. |
| Observer | Project | Read-only. Can view documents, workflow status, transmittals, and reports. Cannot take any action. Suitable for clients or senior management monitoring project progress. |
Permission matrix
The table below shows which permissions are available by default for each role. Access control groups can grant additional permissions beyond the role default.
| Permission | Org Admin | Project Admin | Document Controller | Reviewer | Approver | Observer |
|---|---|---|---|---|---|---|
| Upload Documents | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Manage Documents (edit metadata, delete) | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Start Workflow | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Complete Workflow Step | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ |
| Send Correspondence | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Manage Transmittals | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Manage Review Matrix | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |
| Manage Work Packages | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| View Reports | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Manage Guest Shares | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Manage Distribution Lists | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Manage Members | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |
| Manage Settings | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ |
| View Audit Log | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
Access control groups
Access control groups allow a project admin to:
- Grant additional permissions beyond the user’s role default (e.g., allow a Reviewer to view the audit log).
- Restrict document visibility — a group can be configured so members only see documents matching specific discipline, type, zone, or confidentiality filters.
Users can belong to multiple groups. Permissions are additive across groups — the most permissive rule wins.
See Access Control Groups Guide for full configuration steps.
Permission inheritance
Permissions flow from org-level to project-level:
- Org Admin role overrides all project-level settings — an Org Admin always has full access to every project.
- Project roles apply within the project. A user with Project Admin on Project A has no elevated access on Project B unless also granted there.
- Access control groups apply only to the project they are configured in.
- When a user is added to multiple access control groups, they receive the union of all group permissions.
Granting and changing roles
- Go to Team in the left sidebar.
- Find the team member to update.
- Click their row to open their profile.
- Change the Role selector to the new role.
- Click Save.
Role changes take effect immediately. The user receives a notification that their role has changed.
Common configuration patterns
Large project with multiple discipline teams
- Create an access control group per discipline (e.g.,
Civil Team,Structural Team). - Each group has document visibility filtered to their discipline.
- Give all reviewers the Reviewer role + their discipline group.
- Document controllers get Document Controller role + no group restriction (they see all).
Client with limited view access
- Assign the Observer role.
- Create an access control group that restricts document visibility to Approved and Issued documents only (no Draft or Under Review).
- Add the client to this group.
Senior approver with admin needs
- Assign Project Admin role.
- If they should not manage settings, leave them without a settings-granting group.
- Note: Project Admin inherits Manage Settings by default — if you need a read-heavy admin, consider using Document Controller + a custom group with elevated permissions instead.