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.
Visibility
Every project is either open or restricted.
| 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.
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 | Can read | Can write | Can manage project settings |
|---|---|---|---|
| Admin | Yes | Yes | Yes |
| Lead | Yes | Yes | Yes |
| Member | Yes | Yes | No |
| Viewer | Yes | No | No |
Project management includes access grants, workflow configuration, custom fields, and saved board settings. Writing includes creating and editing tickets, adding comments, changing status where workflow rules allow it, and updating project work.
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.
Direct User Grants
Direct grants assign a project role to specific members. Use direct grants for:
- Project leads.
- A few known contributors.
- Exceptions to a group rule.
- Temporary access during a review or handoff.
When a person has both a direct role and a group role, TOW uses the strongest applicable project role.
Group Grants
Group grants assign access to every member of an organisation group. Use groups for repeatable access patterns such as engineering, customer success, leadership, or implementation teams.
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 grant is only as accurate as the group membership behind it.
Restricted Project Access
Restricted projects require explicit access. A member without a direct or group grant 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:
- Is the project visibility still correct?
- Do project leads have admin or lead access?
- Are broad contributors members rather than admins?
- Are viewers read-only where needed?
- Do group grants reflect current team structure?
- Are direct grants still necessary?
- 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.