> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/administer-and-govern/control/members.md). # Members Manage Project membership, built-in and custom roles, effective access and member previews in Lleverage. Use **Members** to manage who belongs to a Project and to understand the access each person actually has. The page brings direct membership, inherited organisation access and other access sources into one view. When access is not obvious, open the member's access details rather than inferring permissions from the role label alone. ## Project roles The built-in Project roles are **Admin, Builder, Operator and Guest**. Projects can also define custom roles with narrower area and item permissions. * Use **Admin** for people who need full Project administration. * Use **Builder** for people who create and improve Project capabilities. * Use **Operator** for people who run the operational experience made available to them. * Use **Guest** when someone should start with no broad Project access and only receive explicitly shared items. * Use a **custom role** when the built-in roles are broader than the person's responsibility. ![Project Members showing a custom role, Guest access and item-specific access](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-9c25ea0b551a7610009e14ec89cbb43818e2211b%2Fmembers-custom-role-guest.png?alt=media) For the complete model, see Roles and Permissions. ## Configure access in practice For a normal Project handoff, use this sequence: 1. Open **Control → Members** and add or invite the person. 2. Choose the narrowest built-in role that matches their responsibility. If the built-in roles are too broad, use a Project-specific custom role with **None, View or Edit** for the relevant areas. 3. If the person only needs a specific App, Workflow, Table or Knowledge Base, prefer **Guest + item sharing** instead of broadening their Project role. 4. Use **Preview as this member** before handoff when the access boundary is not obvious. 5. If the result is unexpected, inspect the person's **effective access and access sources** in Members before changing roles. Their access may also come from organisation ownership, directory or local groups, or item-level sharing. This keeps the access decision tied to the person's real operational responsibility and gives you a repeatable way to verify the result before they start using the Project. ## Add or invite people From the Project's Members page, add an existing organisation member or invite a new person, then choose the narrowest appropriate role. Custom roles can be assigned directly to people. If a person only needs a specific App, Workflow, Table or Knowledge Base, prefer item sharing over giving a broader Project role. ## Understand effective access A person's access can come from several sources. For example, they may have a direct Project role, inherited organisation-owner access, a group grant, or access to a specific item. The Members page shows the effective result and its sources. This is the canonical place to investigate why someone can or cannot reach part of a Project. ### Organisation ownership An Organisation Owner has effective Project Admin access even if there is no direct Project membership row. Their inherited access is managed at organisation level, not from the Project member-role selector. ## Preview as a member Where your own access allows it, choose **Preview as this member** to inspect the Project from that person's effective access boundary. Use preview before an invitation or access change when you need confidence about what the customer or colleague will actually see. A visible preview state identifies whose access you are inspecting. Exiting preview returns to your own access; preview does not mutate the member's permissions. ## Review access over time Revisit Project access when responsibilities change. Prefer the narrowest durable role or item grant that matches the person's work, and remove direct access that is no longer needed instead of relying on UI hiding alone. --- # 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.lleverage.ai/administer-and-govern/control/members.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.