When you invite a community X to the member group of a workspace Y, you could expect that community X simply becomes another member of workspace Y. But this is not so, because then community X would be a member of two workspaces: of Y and of its own community workspace. Instead, when you invite a community X to a workspace Y, you actually invite the member group of the community workspace X. Community X does not become a member of workspace Y, but the member group of the community workspace X which includes community X. This also implies that workspace Y is made part of community workspace X. If the community role of X is Restricted member or Anonymous member, all community members can access workspace Y only in the role Anonymous member regardless of the role in which community X has been invited; otherwise, the members of community X can access workspace Y in the community role of X (also cf. 4.4.3).

Consequently, when you invite a community X to a community workspace Y, the member group of community workspace X becomes a member of community workspace Y, and community workspace Y becomes a subfolder of community workspace X. This way you can easily create a hierarchical organization of existing community workspaces. Note that the communities concerned have no similar relations: no community is a subcommunity of another.

Keep in mind that inviting a community to a workspace is to be distinguished from adding a community to a workspace as described above in 7.3.2 (using   Access    Add Community  or implicitly using  | to community | ). Adding a community to a workspace is only possible for a workspace manager if the workspace has no community as member yet, while inviting communities has no such restrictions.