> ## Documentation Index
> Fetch the complete documentation index at: https://meganharrisonconsulting.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage User Access

> Manage users, roles, project access, and sensitive modules.

[User Management](/settings/user-management) controls which tools a person can see and what they can do inside
those tools. Use it carefully because access changes can expose project,
financial, document, and directory information.

User Management controls people, projects, roles, and exceptions. Page-level
access is reviewed from Site Map. Do not change a role template just to make one
page visible unless the role should also gain that module access everywhere else.

## Company-Level Access

1. Open [User Management](/settings/user-management) from the company tools area.
2. Use **User Management** to review each user's current access.
3. Open a user to review company access, project access, and overrides.
4. Assign the correct company or project role.
5. Save the change.

## Roles

Use roles when multiple people need the same access pattern.

* **Company roles** apply across the company.
* **Project roles** apply to project-specific access.
* Granular access should be used when a role is close but not exact.

Roles are permission templates. A project membership can have its own project
role; a company template can act as fallback when there is no project role.
Runtime permission checks prefer the project role first.

## Project-Level Access

For project-specific access, open the project and go to **Project User Management**.
Use this when someone should only access one project or needs a different role
on one project than they have elsewhere.

Project access is the first gate. If the user is not assigned to the project,
they cannot use most project-scoped tools even if a role template exists.

## Page-Level Access

Use Site Map when the question is, "Which roles can open this page?"

* **Allowed Roles** controls the explicit page allowlist.
* **Roles That Qualify** is only diagnostic. It shows which roles satisfy the
  current module requirement.

Selecting roles in **Allowed Roles** does not edit the role template. It creates
or updates the page access policy for that route.

## Before You Save

* Confirm the person needs the access for their current work.
* Avoid admin access unless the person truly needs it.
* Prefer roles over one-off overrides when the same access pattern will be
  reused.
* Review financial and document access carefully before expanding access.
* For a single page, use Site Map **Allowed Roles** instead of broadening the
  role's module permissions.