Permissions
Permissions answer three everyday questions:
- Can this person open the project?
- Can this person change the work inside it?
- Can this person manage who else has access?
Most project managers only need three controls:
- Organisation role: what someone can do across the workspace.
- Project visibility: whether a project is open to the workspace or restricted.
- Project role: what a person or group can do inside one project.
For practical setup notes, use the How-To Guides:
The Short Version
| Goal | Use this |
|---|---|
| Everyone in the organisation can see and edit the project | Open project |
| Only selected people or groups can see the project | Restricted project |
| A group can see the project but not edit tickets | Restricted project + Viewer role |
| A group can see and edit tickets | Restricted project + Member role |
| A person can manage project settings and access | Project Admin or Lead role |
| Someone should manage the whole workspace | Organisation Owner or Admin |
If you are protecting customer work, hiring plans, legal work, executive planning, or security work, use a restricted project.
Organisation Roles
Organisation roles are broad workspace roles.
| Organisation role | What it means |
|---|---|
| Owner | Accountable workspace administrator. Can manage members, groups, organisation settings, permission settings, and security settings. |
| Admin | Delegated workspace administrator. Usually has the same day-to-day admin powers as Owner. |
| Member | Normal teammate. Can use the workspace and work in projects they can access. |
Use Owner/Admin for people who should administer the workspace, not just lead one project.
Project Visibility
Every project is either open or restricted.
| Visibility | Who can see it | Who can edit tickets |
|---|---|---|
| Open | Organisation members | Organisation members |
| Restricted | Only granted users and groups | Only granted users and groups with edit roles |
The important part: open projects are writable. Open does not mean "everyone can view but only some people can edit."
If you want most people to view but only a few people to edit, use a restricted project and grant:
- Viewer to the people or group that should only read.
- Member, Lead, or Admin to the people or group that should edit.
Project Roles
Project roles apply inside one project.
| Project role | Can view project | Can edit tickets | Can manage project settings |
|---|---|---|---|
| Viewer | Yes | No | No |
| Member | Yes | Yes | No |
| Lead | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes |
Editing tickets includes creating tickets, changing ticket fields, commenting, moving work through workflow statuses, and updating project work. Some moves can still be blocked by workflow rules, such as required fields.
Managing project settings includes project access, workflow, custom fields, boards, and similar project configuration.
Users and Groups
You can grant project access directly to a person or through an organisation group.
Use groups when access should follow a team:
- Engineering
- Customer Success
- Leadership
- Implementation Team
- Finance Review
Use direct user grants for exceptions:
- A project lead.
- A temporary reviewer.
- One person helping with a handoff.
When a person receives access from more than one place, TOW uses the strongest role that applies.
Example: if Ana is in a group with Viewer access and also has a direct Member grant, Ana can edit because Member is stronger than Viewer.
Common Scenarios
| Scenario | Recommended setup |
|---|---|
| Only the Delivery group should see and edit a customer project | Restricted project. Grant Delivery the Member role. Grant project owners Lead or Admin. |
| Leadership can read a project but only operators can edit it | Restricted project. Grant Leadership Viewer. Grant Operators Member. |
| One person needs temporary edit access | Add a direct Member grant. Remove it after the review. |
| A project should be private except for two leads | Restricted project. Grant those leads Lead or Admin. |
| Everyone should help maintain an internal planning project | Open project. |
| A person cannot find a project | Check project visibility, direct grants, group grants, and organisation membership. |
| A person can open a project but cannot move a ticket | Check their project role and the workflow rule for that transition. |
Workflow Rules Still Apply
Permissions decide whether someone is allowed to try an action. Workflow rules can still block the action.
For example, a Member may be allowed to edit tickets, but a workflow can still block moving a ticket to Done until required fields are filled.
When a user cannot move work, check both:
- Their project role.
- The workflow transition rules.
Sensitive Items
Some records can also have item-level security. This is an extra lock on top of normal project access.
The rule is:
- The person must be allowed to read the project or resource.
- The person must also be included in the item's security level.
Workspace admins can configure permission and security settings, but that does not automatically mean they can read every secured item. Secured content requires membership in the relevant security level.
Most teams should start with restricted projects and groups. Use item-level security only when a few records inside an otherwise accessible project need tighter control.
AI and Search
AI, search, TQL, snapshots, references, and exports should only show information the user is allowed to see.
This means:
- Chat should not use hidden project work as context for a user.
- Search should not return hidden tickets or docs.
- TQL should not reveal hidden tickets through results.
- Exports should be treated as sensitive because they can contain many records.
What To Review Regularly
Review access when a team changes, a customer engagement starts or ends, or sensitive work begins.
Check:
- Is the project open or restricted?
- Are the right groups granted?
- Are direct user grants still needed?
- Are viewers truly read-only?
- Are project admins still the right owners?
- Are organisation admins limited to people who need workspace-wide control?