Use groups for project access

Groups are the easiest way to keep project access maintainable. Add people to a group once, then grant that group access to the projects it owns or reviews.

Current UI support

You can create and maintain groups in Organisation Settings > Groups. Project group grants are supported by the backend, but the current project Members panel only exposes direct user grants. Use API/admin tooling for group grants until the project settings UI exposes them.

When to use a group

Use a group when:

1. Several people need the same project access.
2. Team membership changes over time.
3. Onboarding should automatically give access to a set of projects.
4. You want access to match real teams such as Engineering, Customer Success, Leadership, or Finance.

Use direct project grants for one-off exceptions.

Create a group

1. Open Organisation Settings.
2. Open Groups.
3. Enter a clear group name.
4. Add a short description when the purpose is not obvious.
5. Create the group.
6. Add members.

Good group names are boring and specific:

• Engineering
• Customer Success
• Leadership
• Finance Review
• Project Phoenix Delivery

Avoid vague names such as Special Access or Important People.

Add a person to a group

1. Open Organisation Settings.
2. Open Groups.
3. Find the group.
4. Add the person.
5. Confirm the group member count changed.
6. Tell the person which projects the group can access.

Group membership can grant access to several projects. Check the group purpose before adding someone.

Remove a person from a group

1. Open Organisation Settings.
2. Open Groups.
3. Find the group.
4. Remove the person.
5. Review whether they also have direct project grants.
6. Remove direct grants if they should no longer have access.

Removing someone from a group does not remove direct project grants.

Grant a group access to a project

1. Create or update the group in Organisation Settings > Groups.
2. Grant the group access through API/admin tooling.
3. Choose the project role:
   • Viewer for read-only stakeholders.
   • Member for people who should edit tickets.
   • Lead or Admin for project owners.
4. Ask one group member to confirm they can access the project.
5. Ask one non-group member to confirm they cannot access it if the project is restricted.

If you need to do this only through the current UI, add the same people directly in Project Settings > Members and choose the matching role.

Change a group's project role

1. Update the group grant through API/admin tooling.
2. Change the role.
3. Tell the group what changed.

Changing a group role affects every member of that group.

Use groups for read-only stakeholders

1. Create a stakeholder group, such as Leadership Review.
2. Create the project as Restricted, or have an admin update an existing project through API/admin tooling.
3. Grant Leadership Review the Viewer role through API/admin tooling.
4. Grant the delivery team the Member role.
5. Grant project owners Lead or Admin.

This keeps stakeholders informed without letting them accidentally change tickets.

Keep groups clean

Review groups when:

1. A person joins or leaves the organisation.
2. A person changes teams.
3. A customer project starts or ends.
4. A project becomes sensitive.
5. A group is used for more than one project.

For each group, check:

• Does the name still match the team?
• Are all members still correct?
• Does the group have access to the right projects?
• Is the group role too powerful anywhere?

Related guides: Control who can access a project, Review access before sensitive work, Onboard a workspace and teammates.