Manage project members

Project members decide who can use a project

Use Manage members when someone needs access to the whole project: the project overview, project views, project canvases, project members, and the canvases that are available through that project. Project membership is project-level access. It is related to workspace membership, but it is not the same thing.

Those differences are expected:

• A workspace member can belong to the workspace and still be outside a private project.
• An external collaborator can be invited to one project without becoming a workspace member.
• A person can open one canvas from a direct canvas share without seeing the project that contains it.

ALLO keeps project access and canvas access separate so owners can share the right amount of work.

For the broader role model, read Members, guests, and external collaborators. For canvas-only sharing, read Share a canvas.

Availability

Member, participant, guest, and external collaborator

ALLO can show different words depending on how a person reached the project.

Do not use the workspace People list as the project member list. People tells you who belongs to the workspace. Manage members tells you who has access to this project.

Open Manage members

Open the project, then choose Manage members from the project header or the project more-actions menu. In some project lists, the project row can also expose member actions.

The project menu can include other project actions such as project details, project tags, duplicate, Starred, archive, leave, or copy link. Manage members is the access action. Manage canvas tags changes tags used by canvases in the project; it does not invite people.

If Manage members is missing, you may be in a shared or restricted view, a demo workspace, an archived project, or a role that can view the project but cannot manage access. Ask the project owner or workspace admin to confirm your permission before changing workspace roles.

Add workspace members, teams, or email addresses

Use the invite field to search workspace members by name or email. If teams are available in your workspace, you can also add a team, which adds the active members of that team to the project.

When you invite by email, ALLO checks whether the email belongs to an active workspace member. Active workspace members stay on the internal project-member path. Emails that do not belong to active workspace members belong on the external collaborator path when external project access is available.

If a teammate does not appear in the picker, check whether they are an active workspace member, whether they are deactivated, and whether you are searching with the email they use for ALLO. If they need normal workspace access, invite them to the workspace or resolve workspace access at that layer first.

Manage external collaborators

External collaborators are people outside the workspace who have access to this project. They do not become workspace members, they usually do not appear in People, and they should not receive access to unrelated workspace work.

In the project member modal, use the footer action to switch between project members and external collaborators when external access is available. The external collaborator view shows the outside people who have access to this project and lets authorized managers invite or remove them.

Use external collaborators for clients, vendors, reviewers, contractors, students in one activity, or anyone who needs this project but should not join the workspace. If the person needs ongoing team context across many projects, invite them as a workspace member instead.

Public and private projects

Project visibility controls who can discover or join the project.

Changing visibility changes the access model:

• Moving a public project to private can remove people who only had broad workspace-public access.
• Moving a private project to public can make the project visible to the workspace.
• If the visibility control is disabled, ask the project owner or workspace admin to review the project setting instead of trying to solve it through unrelated role changes.

Joined and Not joined filters

Projects can expose Joined and Not joined quick filters alongside public/private and due-date filters. Joined means the project is part of your active project participation list. Not joined is useful when your workspace shows public or discoverable projects you can access but have not joined.

These filters do not replace permissions. A private project still needs an invite. A public project can be visible because you are a workspace member. A direct canvas share can appear outside the project list because it is canvas access, not project participation.

For project-list filtering and views, read Use tags and filters and Use project views.

Who can see the project

A person can see a project when at least one valid project access path applies.

If someone cannot find the project, confirm the workspace, the signed-in email, whether the project is public or private, and whether the person was invited to the project rather than only to one canvas.

Who can see canvases inside the project

Project access and canvas access are related, but they are still separate checks. A project can contain or reference canvases that have their own sharing state. A person may be able to open the project but not a restricted canvas inside it. The reverse can also happen: a person can open a directly shared canvas without seeing the whole project.

If someone can open a canvas but not the project, add them from Manage members only if they should have project access too. If they should only see that canvas, keep the access at the canvas layer. See Share a canvas and Fix shared access.

Transfer ownership, remove people, or leave

If owner transfer is available, use it only when the new owner should become responsible for project access and high-impact settings. ALLO may show a confirmation because the current owner can lose owner-only controls after confirming the transfer.

Project owners can usually remove other project members. Non-owners may only be able to leave the project themselves, if leaving is enabled. Workspace admins may have recovery or owner-transfer options in some public project situations, but that does not automatically give them every project-owner action.

External collaborator rows may have fewer role controls than internal members. If an external collaborator has the wrong access, remove or reinvite them from the external collaborator view instead of looking for the same owner-transfer menu used for workspace members.

Project access examples

If a product team keeps a roadmap in a public project, workspace members can discover and join it. The project owner may not need to invite every workspace member one by one.

If the finance team keeps a confidential launch budget in a private project, workspace membership is not enough. Add only the people who should see that project, and share individual canvases only when a reviewer needs a smaller slice.

If a client needs to comment on one design review canvas, share the canvas directly. Inviting the client to the whole project would also expose project context they may not need.

If a contractor needs to update several project deliverables, project membership is usually cleaner than sending separate canvas shares for each work surface.

Missing-button and hidden-state cases

If a teammate has the button and you do not, compare project roles first. If nobody has it, ask a workspace admin to check workspace settings and project state.

Common mistakes

Do not add every outside reviewer as a workspace member. Use external collaborator access when they only need one project.

Do not assume public means anyone on the internet can see the project. Public project visibility is workspace-public, not web-public.

Do not remove a canvas collaborator and assume project access is gone. If the person also belongs to the project, they may still have an access path.

Do not transfer ownership casually. Ownership is a control boundary, not a decorative badge.

Do not keep a former employee as an external collaborator until their old workspace member state is resolved. If they were deactivated, a workspace admin may need to clean up the member state before item-level sharing works as expected.

Troubleshoot project member issues

If someone cannot open the project, confirm the workspace, signed-in email, project visibility, project membership, and whether they are internal or external. Then refresh the project and retry.

If someone can open the project but cannot edit, check their project role and whether the project is read-only, archived, or restricted by workspace settings.

If someone can open the project but cannot open a canvas inside it, ask the canvas owner to check canvas sharing. Project membership may not be enough for that canvas.

If a removed person still appears in activity or comments, that may be historical authorship. It does not always mean they still have access. Test with the project member list and the canvas share list before escalating.

Contact support when an authorized owner cannot add, remove, transfer, or view project members after refresh. Include the workspace name, project name, affected email, whether the person is a workspace member or external collaborator, the action attempted, and screenshots of Manage members.