Project Access, Roles, and Groups
Project access controls who can read, write, and manage project work. It applies to project tickets, boards, custom fields, workflows, roadmap scope, and other project-scoped records.
Use access settings to match the way your organisation actually works. Keep broad work open and restrict sensitive work to the people and groups that need it.
Permission Schemes and Visibility
Every project has a permission scheme. TOW includes immutable Open project and Restricted project schemes that preserve the familiar visibility behavior.
| Visibility | Read access | Write access | Typical use |
|---|---|---|---|
| Open | Organisation members | Organisation members | Shared operating work, broad product teams, internal planning |
| Restricted | Granted users and groups | Granted users and groups with write roles | Confidential work, customer delivery, executive planning, sensitive initiatives |
Organisation owners and admins can manage projects across the organisation.
Organisation admins can create or clone schemes in Organisation Settings > Permissions. The editor shows a card per role with its permission level — No access, View, Contribute, or Full control — which can be applied to the whole role in one step. A Fine-tune dialog adjusts individual permissions per role (prerequisites are enabled together automatically), and an expandable table compares all roles at once for auditing. Custom schemes do not inherit hidden permissions from broader legacy actions: a permission that is off is not granted unless another role or holder supplies it. A custom scheme can be shared by several projects; changing it changes all projects that use it. The editor lists the projects that use the scheme and summarises pending changes before you save.
Imported Jira schemes remain read-only until an administrator takes ownership or clones them. They cannot be newly assigned to a different project. This preserves migration provenance and prevents a later sync from silently overwriting local edits. The scheme editor lists imported group, user, reporter, assignee, custom-field, and composite grants that do not fit the standard-role matrix in an Additional grants audit section.
Changing a project's scheme requires confirmation because access changes immediately. The project picker only offers TOW-managed schemes; clone an imported scheme before assigning its behavior elsewhere.
docs.read, docs.write, and docs.delete limit access that already exists through document sharing. They do not create document ACL entries. For example, granting docs.read to Any org member does not expose a project doc unless that member is also included by the doc or project-space sharing rules.
Open projects give organisation members write access, not only visibility. If a project should be visible but not editable to most people, make it restricted and grant viewer access to the appropriate users or groups.
Project Roles
Project grants use these roles:
| Role | Built-in default |
|---|---|
| Admin | Read, write, and administer |
| Lead | Read, write, and administer |
| Member | Read and write |
| Viewer | Read only |
These are the built-in defaults, not hard-coded role powers. A custom permission scheme determines the exact actions granted to each role.
Imported projects can also contain non-standard Jira roles such as Developers. After takeover, those roles remain effective and appear under Additional project roles in the Access tab. Administrators can audit their holders and remove TOW-managed role actors there instead of leaving invisible access behind.
Organisation Admins
Organisation owners and admins have project management access. They can read, write, and manage projects as part of workspace administration.
Use organisation admin rights sparingly. For day-to-day project ownership, grant project admin or lead roles so responsibility is clear without broad organisation-wide privileges.
Person Assignments
Assign one or more project roles to a specific organisation member. Use person assignments for:
- Project leads.
- A few known contributors.
- Exceptions to a group rule.
- Temporary access during a review or handoff.
Permissions are additive. When a person has several direct roles or also receives roles through groups, TOW uses the union of every permission granted by those roles. There is no explicit deny in the first version.
Group Assignments
Group assignments give one or more roles to every active member of an organisation group. Manage them from the Groups tab in project access.
Group grants are easier to maintain when:
- Several people need the same project role.
- Team membership changes regularly.
- Onboarding should automatically grant project access.
- Access should mirror an operating team instead of individual exceptions.
Review group membership regularly. A group role assignment is only as accurate as the group membership behind it.
Restricted Project Access
Restricted projects require explicit access. A member without a person or group role assignment cannot read or write restricted project work.
Use restricted projects for:
- Sensitive customer engagements.
- Financial, legal, or people-related work.
- Executive planning.
- Security work.
- Initiatives with limited disclosure.
When assigning a ticket to someone in a restricted project, make sure the assignee has project access. TOW requires the assignee to be able to access the project.
Access Review Checklist
Use this checklist before major planning, audits, or customer reviews:
- Does the project still use the correct permission scheme?
- Do project leads have admin or lead access?
- Are broad contributors members rather than admins?
- Are viewers read-only where needed?
- Do group role assignments reflect current team structure?
- Are direct person assignments still necessary?
- Does the project use the intended permission scheme?
- Are external or sensitive initiatives restricted?
Access is part of project quality. A project is easier to operate when the right people can update work and the wrong people cannot accidentally change it.