> 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/directory-access/grant-access-with-directory-groups.md). # Grant access with directory groups Once a directory is connected, access is a matter of mapping a group to a role. Everything below is on **Organisation Settings → Directory** and needs the Organisation Owner role. ## Map a group 1. Under **Group mappings**, select **Map a group**. 2. Search for the group by name. For Entra ID, every group in the tenant is searchable; for SCIM, only groups your IT team has assigned to Lleverage appear. 3. Choose the target: a Project, or the organisation. 4. Choose the role. 5. Read the preview, then select **Map group**. Nothing is granted until you confirm. The preview lists who will gain access, who is unchanged because they already hold that role or a higher one, and who cannot be linked to an account and why. ### Roles | Target | Roles available | Notes | | ------------ | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Project | Admin, Builder, Operator | Current Project roles are described in [Roles and Permissions](/administer-and-govern/control/members/roles-and-permissions.md) | | Organisation | Owner, Member | Member gives organisation membership with no Project access. Owner is full control of the organisation, so mapping a group to Owner asks you to type the group's exact name to confirm. | Custom Project roles are assigned directly to people; directory group mappings use the built-in Project roles above. ### Nested groups For Entra ID, membership is read transitively: a person in a group nested inside the mapped group counts as a member. For SCIM, nested membership depends on what your identity provider sends over SCIM, so test it before relying on it. ### What happens after you confirm Lleverage creates a mirror group in the organisation, named after the directory group and marked as directory-managed. The mirror holds the role; its members are kept in step with the directory. You can see the mirror group on the Project's Members page, and each member shows which group gave them their access. The mapping shows as **Applied** once the first pass through the members has finished. From then on, every sync applies membership changes, and each affected person is refreshed when they sign in. ## Members the directory cannot link A group member is linked to a Lleverage account by email address. When there is no account, Lleverage creates one if **Create accounts before first sign-in** is on and the address is on a domain your organisation has verified, or the unverified-domain setting is on. Anyone who still cannot be linked is listed under **Members without access** with the reason. | Reason | Meaning | What to do | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | No matching account | No Lleverage account with that address, and account creation is off or the domain is not verified | Verify the domain, turn on account creation, or invite the person by hand | | Email domain not verified for this organisation | The address is on a domain the organisation has not verified | Verify the domain, or turn on **Create accounts for unverified email domains** | | Account exists outside this organisation | A Lleverage account with that address already exists but is not a member of this organisation | Invite the person to the organisation, then select **Link to member** | | Matches more than one account | Two Lleverage accounts in the organisation match the address | Select **Link to member** and choose the right one | | Guest from another tenant | A B2B guest in your tenant | Guests are never provisioned by group mappings. Invite them by hand if they need access. | | Account disabled in Entra | The directory account is disabled | Nothing to do; they gain access when the account is enabled | | No email address | The directory record carries no mail or user principal name | Add an address in the directory | A directory address does not have to match exactly: matching ignores case, and **Alias domains** in Sync behaviour lets `someone@contoso.onmicrosoft.com` match `someone@contoso.com`. ## Change or remove a mapping Select **Change role** on a mapping to move the group to a different role. The preview shows who changes and who does not; someone who also holds a higher role directly is unchanged because the highest role wins. Select **Remove mapping** to stop the group granting anything. Members lose the role unless another mapping, a direct grant or an Everyone grant still covers them. The mirror group is archived when no mapping uses it. ## Everyone in the tenant An Everyone grant gives a role to every enabled member of your tenant, not just members of a group. Under **Everyone in \\\[your tenant]**, choose a Project and a role (Builder or Operator), or the organisation (Member). Project Admin and Organisation Owner are never available here. Guests from other tenants are left out unless **Everyone includes guests** is on. Someone who signs in for the first time after the grant exists gets it at sign-in. **Apply to all now** applies it immediately across the tenant instead of waiting for the next sync. ## How directory access sits with other access Access in Lleverage can come from multiple sources and they add up: * **Direct.** An owner gave the person the role, or they accepted an invitation. * **Group.** A mapped directory group, or a local group in the organisation. * **Everyone.** An Everyone grant from the directory. * **Single sign-on.** For organisations that used SSO auto-join before connecting a directory, see the Directory access FAQ. The highest role from any source is the one that applies. The directory only ever adds or removes what it granted. Removing a mapping, a group membership or the whole directory never touches a direct grant. An owner can **suspend** a directory member in a group from the Project's Members page. The sync keeps them in the mirror group, but the role is withheld until an owner unsuspends them. ## When someone leaves | What happens in the directory | What happens in Lleverage | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Removed from a mapped group | Loses that group's role at the next sync, or at once over SCIM. With **Remove access when someone leaves a group** off, keeps it and is listed for review instead. | | Account disabled | Loses every directory-sourced role. With **Sign out disabled accounts** on, sessions in this organisation end within the sync interval. If they also hold direct access, they appear under **Needs review**. | | Account deleted | As disabled | | Account re-enabled | Roles return at the next sync | **Needs review** lists people whose directory account is disabled or gone but who still hold access that was granted directly. The directory never removes that direct access; you decide. **Keep** leaves them as they are, while **Remove all access** removes every grant they hold in the organisation and ends their sessions here. ## Watching the sync **Sync activity** lists recent runs with when they ran, what triggered them, how long they took, and what changed. A run marked as partial ran out of time and will pick up where it left off on the next tick. Organisation Owners get an email when a sync fails, and a digest of access changes unless **Sync digests** is off. Every change the directory makes to access is recorded under **Organisation Settings → Activity → Access activity**, with the group and sync run that caused it. Events are kept for 400 days. --- # 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/directory-access/grant-access-with-directory-groups.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.