Control who can access a project

Use this guide when you want to decide who can see or edit a project's tickets, boards, docs, and project work.

Choose the right access pattern

Before changing settings, decide what you want:

You want	Choose
Everyone in the organisation can see and edit the project	Open project
Only selected people or groups can see the project	Restricted project
Some people can view but not edit	Restricted project + Viewer role
A team can view and edit tickets	Restricted project + Member role
A project owner can manage access and settings	Lead or Admin role

Open projects are writable by organisation members. If that is too broad, use a restricted project.

Current UI support

The current project settings UI lets you manage direct user grants in Project Settings > Members. It does not yet expose controls for changing an existing project's visibility or adding project group grants. Choose visibility when creating a project, or have an admin use API/admin tooling for existing project visibility and group-grant changes.

Allow only one group to view and edit tickets

Use this for customer delivery, confidential initiatives, or any project where one team should own the work.

1. Open Organisation Settings.
2. Open Groups.
3. Create a group for the team, such as Delivery Team.
4. Add the people who should work in the project to that group.
5. Create the project with visibility set to Restricted. For an existing project, have an admin change visibility through API/admin tooling until the UI exposes this control.
6. Open Project Settings > Members.
7. Add the people who should work in the project.
8. Choose Member if they should view and edit tickets.
9. Choose Lead or Admin for the people who should manage project settings.
10. Save the access changes.
11. If you are using project group grants through API/admin tooling, grant the group the Member role instead of maintaining the same users one by one.
12. Ask someone outside the group to confirm they cannot see the project.

Result: only the granted group and project owners can see the project. Members can edit tickets. People outside the group should not see the project in project lists, ticket lists, boards, TQL results, search results, or AI context.

Let a group view but not edit

Use this when leadership, stakeholders, or support teams need visibility but should not change work.

1. Confirm the project is Restricted. For a new project, choose this during project creation.
2. If group grants are being managed through API/admin tooling, grant the stakeholder group Viewer.
3. If you are using only the current UI, open Project Settings > Members and add the stakeholder users directly.
4. Choose Viewer.
5. Save.
6. Open the project as one of those users or ask a teammate to verify.

Viewers can read the project but should not create, edit, move, comment on, or delete tickets.

Let one person edit temporarily

Use a direct user grant for short-term exceptions.

1. Open the project.
2. Open Project Settings > Members.
3. Select Add members.
4. Search for the person.
5. Choose Member.
6. Save.
7. Add a reminder to remove the grant after the review or handoff.

Do not create a new group for one short-term person unless that pattern will repeat.

Make a project visible to everyone but editable by only a few people

Do not use an open project for this. Open projects let organisation members edit.

Instead:

1. Create the project with visibility set to Restricted, or have an admin change an existing project through API/admin tooling.
2. Open Project Settings > Members.
3. Add the broad audience as Viewer.
4. Add the working team as Member.
5. Add project owners as Lead or Admin.
6. Save.

Result: the broad audience can read, while the working team edits.

Remove someone's project access

1. Open the project.
2. Open Project Settings > Members.
3. Find the person.
4. Remove their direct project grant if one exists.
5. Check whether they still belong to a group with project access.
6. Remove them from that group in Organisation Settings > Groups, or change the group grant through API/admin tooling if needed.
7. Save.
8. Ask the person to refresh TOW and confirm they no longer see the project.

Removing a direct grant is not enough if the person also receives access from a group.

Change someone's project role

1. Open the project.
2. Open Project Settings > Members.
3. Find the person.
4. Select Change role.
5. Choose the new role:
   • Viewer for read-only.
   • Member for normal editing.
   • Lead for project ownership.
   • Admin for full project administration.
6. Save.

Keep most contributors as Member. Use Lead or Admin only for people who should manage settings and access.

Troubleshoot access problems

If someone cannot see a project:

1. Confirm they are a member of the organisation.
2. Check whether the project is open or restricted.
3. If restricted, check direct project grants.
4. Check group grants.
5. Check whether they are in the expected group.
6. Ask them to refresh the app.

If someone can see a project but cannot edit:

1. Check whether they are Viewer.
2. Change them or their group to Member if they should edit.
3. If they cannot move a ticket, check workflow transition rules.
4. If they cannot assign a ticket, check whether the assignee can access the project.

If someone can edit more than expected:

1. Check direct project grants.
2. Check every group they belong to.
3. Check whether they are an organisation Owner or Admin.
4. Change project visibility from Open to Restricted through project creation or API/admin tooling if the project should not be broadly writable.

Related guides: Use groups for project access, Review access before sensitive work, Configure workflows and required fields.