Members, groups, and permissions
Domain focus
This domain tests how access is granted and limited: workspace roles, group membership, permission levels, teamspace types, page inheritance, and guest access. The exam favors least-privilege decisions and questions that distinguish direct sharing from inherited access.
Core rules
- Workspace roles are Owner, Admin, Member, and Guest. Guests are external collaborators with access only to what is shared with them; they are not full workspace members.
- Permission levels are Full access, Can edit, Can comment, Can view, and No access. Use the lowest level that supports the task.
- Groups are reusable permission containers. Adding a group to a page or teamspace grants its members the group's permission; removing a member from the group revokes that inherited access.
- Teamspaces can be Open, Closed, or Private. Teamspace members generally see all pages inside that teamspace, so page-level sharing is not a reliable way to hide a teamspace page from other teamspace members.
- Private pages are visible only to the creator and invitees. Page access can be broader than a parent page but should not be assumed to be narrower inside a teamspace.
- SCIM provisioning can automate group and member lifecycle on eligible plans; it does not replace permission design.
Worked example
A contractor needs to edit one project database but must not see the HR wiki. Create or use a guest account, add the contractor directly to the project database with Can edit, and do not add them to a workspace group or the HR teamspace. Reasoning: direct page sharing gives the minimum access; group membership would grant every permission attached to that group; teamspace membership would expose all HR pages in that teamspace.
Traps
Granting Can edit when Can comment is enough; adding a guest to a broad group; trying to hide one page inside a teamspace from other teamspace members; assuming a page share overrides teamspace access.