Members, guests, and external collaborators

Access has three layers

ALLO separates a person’s relationship to the workspace from their permission on a specific piece of work. That separation is the key to understanding almost every “Why can’t they see this?”, “Why is this read-only?”, “Why do they not appear in People?”, and “Why is the invite button missing?” question.

Access questions usually involve four layers:

1. Workspace relationship: whether the person is a workspace member, workspace admin, guest, external collaborator, or deactivated member.
2. Shared-item access: whether the person can open a specific project, canvas, dashboard, file, task, or Goals/OKRs item.
3. Content permission: whether the person can view, comment, or edit that item.
4. Management responsibility: whether the person can change ownership, member access, admin settings, or other higher-risk controls.

That distinction matters because external collaborators are not a workspace directory type. They are people with item-level access. A client can be an external collaborator on one shared project, a reviewer on one shared canvas, and absent from People at the same time.

For a broader workspace overview, start with Understand workspaces. For inviting full members, use Invite workspace members. For narrow outside access, use Invite guests and external collaborators.

Availability and permissions

Workspace relationships and shared-item access

These terms describe either a person’s relationship to the workspace or their access to one shared item. They do not automatically describe what the person can do everywhere in ALLO.

People is for workspace members, teams, and the org chart. It is not a complete list of every person who has ever opened a shared link. If someone is missing from People, check whether they are an external collaborator or guest before inviting them again.

Content-level permissions

Content-level permissions describe what a person can do on one piece of work. The labels can vary by surface, but the practical model is consistent.

Workspace role and content permission combine. A workspace member can be read-only on a private canvas. A workspace admin can still need the correct item context to manage a shared item. An external collaborator can edit one canvas without seeing workspace settings. A guest can comment on a canvas only if the link or invite grants comment access.

Where to check access

Use the right access path

If a deactivated person later needs access only as an external collaborator, an admin must resolve the member state and share the specific work again instead of relying on the old membership.

Common scenarios

Permission and visibility notes

Keep these distinctions separate:

• Directory visibility is not access visibility. People is the member directory for workspace members, teams, and the org chart. A canvas or project permission list is the access list for that item.
• Historical visibility is not current access. Activity, comments, notifications, and authorship can show names connected to past work without making that person an active workspace member.
• Workspace admins manage workspace-level access. Item owners and managers manage item-level access. Avoid turning every item access problem into a workspace admin role change.
• External collaborators and guests should get the smallest access that works. Use view or comment for review, edit for contribution, and workspace membership only for ongoing team participation.
• Deactivated member access is intentionally strict. A deactivated member should not regain workspace access through an old canvas URL, project link, socket connection, or shared item path.

Common mistakes

• Copying a URL and assuming access was granted. A URL can point to private work. If the recipient sees an access error, update the sharing settings or invite them with the right permission.
• Adding an external reviewer as a workspace member. That can expose them in the directory, use a seat, and make cleanup harder. Use Invite guests and external collaborators when access should be narrow.
• Changing a workspace role to fix a private canvas or project. That is usually too broad. Fix the item permission first with Share work with teammates, Share a canvas, or project Manage members.
• Assuming Teams grant universal access. Teams organize workspace members. The item still needs to allow the team or member where sharing is required. See Manage teams.

Recover when access looks wrong

1. Check the signed-in account. Many access problems come from accepting an invite with one email and opening the link while signed in with another email.
2. Confirm the active workspace. A valid link can still look wrong if the person is viewing a different workspace.
3. Decide whether the issue is workspace membership or item permission. If the person is not in People and should be, send or resend a workspace invite. If they can open the workspace but not a specific canvas, update that canvas’s permission.
4. If the person was deactivated, ask a workspace admin to choose the right recovery: reactivate them as a workspace member, or resolve the old member state and share one item as an external collaborator. Do not tell them to keep retrying old links.
5. If the problem started from Inbox, a notification, or an old email, check whether the original work was deleted, moved, archived, or unshared. Then use When work looks missing or Shared with me troubleshooting.