> 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/roles-and-permissions.md). # Roles and permissions Understand built-in and custom Project roles, item sharing and how effective access is resolved in Lleverage. Project access combines **built-in roles**, optional **custom roles**, and access to specific items. The Members page shows the effective result and where that access came from. ## Built-in Project roles The current built-in Project roles are: * **Admin** — full Project access, including member and role administration. * **Builder** — creates and improves operational capabilities such as Workflows, Tables, Knowledge Bases and other builder surfaces. * **Operator** — uses the operational surfaces made available to them, such as Apps, Agent sessions and Requests. * **Guest** — intentionally starts without broad Project access. Give a Guest access only to the specific items they need. The built-in roles remain available as stable defaults. Existing Admin, Builder and Operator access was preserved when custom roles were introduced. ## Custom roles Project Admins can create Project-specific roles when the built-in roles are too broad. A custom role can set **None, View or Edit** for Project areas and can include access to specific **Apps, Workflows, Tables and Knowledge Bases**. This lets a person work with the part of the Project they need without receiving a broad Builder or Admin role. Custom roles are assigned directly to people. Directory group and Everyone grants continue to use built-in roles. When an item can execute or change operational state, the relevant **Edit** permission on that resource remains the authority boundary. App and Workflow permissions are separate: access to one does not silently grant access to the other. ## Sharing individual items Apps, Workflows, Tables and Knowledge Bases can be shared with an eligible person or role without broadening the recipient's access to the whole Project. This is especially useful with Guest or narrowly scoped custom roles. A shared URL by itself is not an access grant; Lleverage still resolves the person's effective Project and item access when they open or use the resource. See [Sharing](/build-and-improve/automate/publish-apps-and-apis/sharing.md) for the item-sharing pattern. ## Effective access and access sources A person's effective access can come from more than one source, including direct Project membership, organisation ownership, directory/local groups and item-level sharing. The Members page explains the effective role and access sources rather than requiring you to infer them from one membership row. Use **Preview as this member** from the Members page when you need to check what a person can actually see before inviting them or changing their access. Preview is an inspection tool; it does not change the member's permissions. ## Organisation Owner Organisation roles remain **Owner** and **Member**. Organisation ownership is separate from Project membership. An Organisation Owner resolves to effective **Admin** access in Projects, so they can appear on the Members page as having access via the organisation even without a direct Project membership row. Change that person's organisation role under organisation settings rather than trying to edit the inherited Project access. ## Legacy Project role data Older Project data can still contain legacy membership values. Do not use those legacy values when designing new access. New Project-access decisions should use Admin, Builder, Operator, Guest or a Project-specific custom role. ## SSO and directory-managed access Enterprise SSO authenticates users through your identity provider. What Project access it produces depends on whether a directory is connected: * **Without a directory**, SSO can establish organisation membership; Project access is then granted separately according to the organisation's configuration. * **With directory access**, mapped groups and Everyone grants can provide built-in Project roles. Direct grants can coexist with directory grants, and the effective access shown in Members reflects all applicable sources. See [Enterprise SSO Setup](/administer-and-govern/control/members/sso-setup.md) and [Directory access](/administer-and-govern/control/members/directory-access.md). RBAC continues to evolve. These docs describe current deployed behaviour rather than a future permission model. --- # 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/roles-and-permissions.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.