Review access before sensitive work

Run this review before starting confidential customer work, legal work, hiring plans, security work, executive planning, or anything that should not be broadly visible.

Start with the project

1. Open Projects.
2. Open the sensitive project.
3. Check the visibility badge in the project header.
4. Confirm visibility is Restricted.
5. Confirm the project lead is still correct.
6. If an existing project needs a visibility change, have an admin update it through API/admin tooling. The current General panel does not expose visibility editing.

Restricted visibility is the baseline. Do not rely on people "knowing not to look" in an open project.

Review who can access it

1. Open Project Settings > Members.
2. Review every direct user grant.
3. Review group grants through API/admin tooling if your workspace uses them. The current project Members panel shows direct user grants.
4. Confirm broad groups are not accidentally included.
5. Confirm each role is appropriate:
   • Viewer for read-only stakeholders.
   • Member for contributors.
   • Lead or Admin for project owners.
6. Remove stale direct grants.
7. Update group membership when team membership has changed.

If a person receives access from a group and a direct grant, the stronger role applies.

Check read-only stakeholders

1. Identify people who need visibility but should not edit.
2. Put them in a stakeholder group.
3. Grant that group Viewer through API/admin tooling, or add the same people directly as Viewer in Project Settings > Members.
4. Confirm they do not also have Member, Lead, or Admin through another group.

This is the safest pattern for leadership review, customer observers, and cross-functional readers.

Check ticket movement rules

1. Open Workflow.
2. Review restricted transitions.
3. Check whether sensitive transitions require a minimum role.
4. Check required fields for handoffs and approvals.
5. Save only intentional changes.

Permissions decide who can work in the project. Workflow rules decide whether a specific status move is allowed.

Check docs and knowledge

1. Open project docs.
2. Remove or relocate docs that belong in a more restricted project.
3. Review memory, decisions, risks, and snapshots related to the project.
4. Confirm sensitive records are scoped to the project or appropriate audience.

Sensitive information can leak through summaries if the source record is too broadly visible.

Check AI surfaces

Review the places where project information may appear:

1. Chat: ask project-specific questions from the right project scope.
2. Inbox: check pending suggestions before applying them.
3. Snapshots: review generated summaries before activation.
4. Search and references: confirm hidden records do not appear for people who should not see them.
5. TQL: run a basic project query as a permitted user and, when possible, as a non-permitted user.

AI should follow the same access rules as the rest of the app, but sensitive teams should still review generated summaries carefully.

Check exports

1. Open organisation settings.
2. Review who can run exports.
3. Treat exports as confidential files.
4. Store exported files only in approved systems.
5. Delete temporary copies after use.

Exports can contain many records at once, so they deserve extra care.

Finish with a simple sign-off

Before work starts, write down:

1. Project name.
2. Why it is restricted.
3. Groups with access.
4. Direct user exceptions.
5. Project owners.
6. Date of the next access review.

Put the note in a project doc so future admins understand the intent behind the access setup.

Related guides: Control who can access a project, Use groups for project access, Review AI proposals.