> For the complete documentation index, see [llms.txt](https://docs.nested-knowledge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nested-knowledge.com/collaborate/member-management/permissions-and-inheritance.md). # Permissions and Inheritance Learn how Organization membership, ownership, and nest-level roles determine access. In Nested Knowledge, you rarely grant access one person at a time. Access flows—from an Organization to its members, and from a nest's ownership to people with roles in the owning Organization. This lets you manage access once at the Organization level, rather than nest by nest. For what each role can do, see [Roles](/collaborate/member-management/roles.md). ### Two Levels Where Access Is Granted You grant access at the nest or Organization level. At the nest level, you grant access to an individual or Organization on one nest. At the Organization level, members inherit access to every nest the Organization can reach. This turns access management into a single decision. ### How Organization Membership Cascades When an Organization receives access to or ownership of a nest, all members receive access automatically. You don't need to add each member or invite them to each nest. The role they receive depends on whether the Organization owns the nest or has access to it. ### Ownership Versus Access Ownership changes what members can do. If the Organization owns the nest, members inherit a nest role that mirrors their Organization role: Organization **Owners** and **Admins** become nest **Admins**, while Organization **Members** become nest **Users**. Everyone in the Organization then has access without a separate invitation. If the Organization has access to the nest but doesn't own it, every member receives User access, regardless of their Organization role. Treat this as bulk sharing, not a transfer of control. Only one Organization can own a nest, but any number can receive access. ### Overrides On A Single Nest Within an individual nest, you can raise a person's access. For example, you can promote an Organization **Member** to **Admin** on one nest. You can't lower access below the inherited role: an Organization **Admin** can't become a **User** on a single nest. Inherited access sets the floor. Nest-level changes can only build on it. ### Teams As A Narrower Scope Teams limit ownership and access to a subset of an Organization's members. Team members can access their team's nests, while other Organization members can't. By default, a team member keeps their Organization role. You can override it with a team-specific role. See [Teams](/collaborate/member-management/teams.md). ### When Access Is Removed Removing a person from the Organization revokes their inherited access to its nests. It doesn't remove them from nests they own. Transfer ownership before removing them. See [Manage or remove members](/collaborate/member-management/manage-or-remove-members.md) for more. ### Templates Follow Ownership When an Organization owns a nest, its templates populate into it. Every Organization template is also available to its teams. See [Organizational Templates](/account-management/organization-management/organization-settings/organizational-templates.md). ### See Also


Invite Members to Your Organization	Add people who need access to every nest in your organization.	Invite Your Team
Manage or Remove Members	Change member roles, remove members, or withdraw pending invites.	Manage Or Remove Members
Roles	Understand organization and nest role permissions.	Roles
Teams	Organize members and nests into focused teams.	Teams

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nested-knowledge.com/collaborate/member-management/permissions-and-inheritance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.