Qumuna sub-communities explained
By Qumuna Editorial Team · Reviewed by Qumuna Product Review
Create nested spaces for distinct groups or work, choose appropriate visibility, give each space its own membership and content, and keep parent-community oversight without treating it as a separate platform.
Short answer: Sub-communities let a Qumuna community create focused spaces beneath its main community. Each can have its own members, roles, handbook, and content while remaining connected to the parent structure and its administration.
Give focused groups their own space
A sub-community can support a committee, location, project, or interest group without mixing every discussion and file into the parent community. Sub-communities can be nested and can link to organizational units or other community entities where the plan and configuration allow.
Choose membership and visibility carefully
Visibility can be restricted, listed, open, or public according to the available settings. Hidden or private spaces are not generally visible to non-members, and public metadata does not make a visitor a member. Joining a sub-community requires membership of its parent community.
Manage lifecycle and merge boundaries
Parent administrators can oversee eligible descendant spaces, while names must remain unique among live siblings and avoid unlinked organizational-unit collisions. Merging is a destructive consolidation: content, members, children, and handbook material are combined or re-pointed and source spaces are moved to trash, not retained as independent copies.
Related resources
Next step
Sketch the smallest hierarchy that matches real responsibilities, decide who should discover and join each space, and pilot one sub-community before creating several. Check current plan availability first.
