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 permission scheme in the project's Access tab.
4. Confirm it is Restricted project or an appropriate custom scheme.
5. Confirm the project lead is still correct.
6. If the project needs a different scheme, ask an organisation admin to choose or create it.

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 the project's Access tab.
2. Review every person role assignment.
3. Open Groups and review every group role assignment.
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 role assignments.
7. Update group membership when team membership has changed.

If a person receives several direct and group roles, all granted permissions are combined.

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 from the project's Access > Groups tab.
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.