This walkthrough gives the right people access to a private Space, Subspace, or Activity, verifies the boundary from both sides, and removes access without confusing membership with authority.
Before You Change Access
Only the Space owner has the current verified path for adding or removing private members. A person with delegated Space-management access may be able to open Private members and review its list, but that visibility does not promise permission to change it. Ask the owner to make the change when you are not the owner.
Confirm the intended privacy boundary before changing its members. Privacy is chosen when the area is created and cannot currently be switched after publication. If the original boundary is wrong, do not treat the member list as a substitute for making a public area private or a private area public. See Privacy for the full hierarchy and access model.
Private publication includes the creator so the new area does not immediately lock them out. The Space owner also retains recovery access to private areas under their Space if an ordinary membership entry is missing. These safeguards preserve access to the area; they do not assign a Role or give another member owner-level authority.
Find The Protecting Scope
A private parent protects its children. The correct member list is therefore the list for the nearest private boundary that grants the access you want to change, not necessarily the page where someone first notices that content is hidden.
•Check the root Space first - If the Space itself is private, its member list controls entry to the Space and everything below it.
•Check the Subspace next - In a public Space, a private Subspace protects that Subspace and all of its Activities.
•Check the Activity itself - In a public Space and public Subspace, a private Activity owns its own access list.
•Avoid changing the wrong list - If an Activity is protected only because its parent Subspace is private, manage access from the Subspace. Adding someone only to another child area will not grant entry through the protected parent.
Once you know the protecting scope, open that exact area before entering its settings.
Open Private members
•Open the protecting area - Go to the private Space, Subspace, or Activity whose boundary you identified.
•Open its settings - For a root, open Space Settings. For a Subspace or Activity, use that area's menu and choose Settings.
•Select Private members - The page is available for a private area and identifies the users who currently have access to that scope.
•Recheck the context - Before editing, confirm the surrounding Space and selected area are the ones you intended. Similar area names can make a correct-looking member list belong to the wrong boundary.
If Private members is missing, first check whether the selected area is public or merely inherits privacy from a parent. Return to the protecting parent rather than looking for a privacy switch in the child.
Add People At The Right Level
The add flow deliberately differs between a private root Space and a nested private area.
•Select Add members - Open the Choose members dialog, then use Add user to find each person you want to include.
•For a private root Space, choose the account to invite - The resulting invitation will not silently make the person a joined member or grant immediate entry.
•For a private Subspace or Activity, choose existing Space members - The nested picker searches among people already associated with the Space. Submitting the selection adds them directly to that protected area.
•Submit the selection - Select Publish in the chooser. At a root Space this starts invitations; at a nested area it stores access for the selected Space members.
•Wait for root acceptance - The recipient must accept the invitation before the private Space appears in their joined navigation and they can enter it. Use Invite and Manage Members to follow the invitation through acceptance and Members and Invites to understand the resulting member states. •Confirm the list - For a nested area, check that each selected person appears on Private members. For a root Space, review the invitation state and verify the member after acceptance rather than treating a sent invitation as completed access.
If someone cannot be found for a nested area, make sure they have first joined the parent Space. Invite them to the Space, wait for acceptance, and then return to the nested area's Private members page.
Verify Allowed And Denied Views
Do not finish with the owner view alone. Privacy affects direct routes, navigation, connected content, and media, so verify one person who should have access and one who should not.
•Check the allowed account - After any required invitation acceptance, ask the added member to refresh and open the protected area from normal navigation.
•Open representative work - Confirm the allowed member can reach content inside the area, such as its About content, posts, documents, Chat, or other work that belongs to that scope.
•Check inherited access - When access was added at a private Space or Subspace, confirm the member can also enter a child area protected by that parent.
•Check a denied account - A signed-in person who is not a member of the protecting boundary should not see the area or its private work in broad navigation and discovery surfaces.
•Try a direct destination - Opening a known protected link as the denied person should not reveal the area or its contents. A direct link must not bypass the member list.
•Review shared guidance - Do not pin content from a private Subspace or Activity to the shared Space panel. Current pin previews cannot guarantee that the private source title and thumbnail stay hidden; Community Guidance explains the safe boundary. •Separate entry from actions - If the allowed person can enter but cannot perform an action, the access boundary may already be correct. Check their Role instead of repeatedly removing and re-adding private membership.
Remove Access Carefully
Removing a private member blocks entry to that boundary after their access state refreshes. It does not delete the person's account, remove unrelated Space membership, or clear Roles assigned through a separate administration flow.
•Return to the exact protecting scope - Open its settings and select Private members again. Do not remove someone from a child list when the parent is the boundary granting their access.
•Select the remove control - Use the delete control beside the intended person and check the name in the Remove member? confirmation.
•Confirm Remove - The person should disappear from the scoped list. You can add them again later if the decision changes.
•Keep a trusted member present - Do not clear the private list or use removal to try to revoke the Space owner's recovery access. Preserve the creator, owner, or another trusted active member while reorganizing access.
•Verify the removed view - Ask the person to refresh. The protected area should disappear from views that previously exposed it, and its direct destinations should no longer open.
•Check unaffected relationships - Confirm that unrelated Space membership and separately assigned Roles remain as intended. Remove or change those only through their own administration pages.
For a private root Space, removing protected access is not the same as removing the person's joined relationship. Review Members and Invites before making a broader membership change.
Handle Responsibilities Separately
Private membership answers whether a person may enter. Roles answer what they may do after entering. Adding someone to a protected Activity does not make them an Activity manager, moderator, coordinator, or publisher.
If the member needs additional responsibility, first verify private entry, then assign the narrowest suitable Role and test the relevant action in that area. Roles and Permissions explains Space-wide grants, area scope, and local overrides. Even a delegated Manage Space capability should not be treated as permission to add or remove private members while the verified change flow remains owner-only.
Result
The private boundary now has a deliberate member list at the correct scope. Added people can enter only after the appropriate root invitation or nested assignment, denied people cannot discover or open protected work, and any operational authority remains separately controlled through Roles.
