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

# Access & Permissions

> Understand how roles, teams, and application access work in Monocle

Monocle uses a two-layer permission system: **organization** roles for managing the workspace, and **team-based application access** for deciding who can use each app.

The key idea: being part of an organization doesn't automatically grant access to every application. Access is distributed through **teams**.

## Organization roles

Organization roles control who can manage the workspace itself.

| Role       | What they can do                                                                                                                                              |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin**  | Manage members, invitations, teams, billing, integrations. Create, edit, and delete applications. Assign team access to apps. Has access to all applications. |
| **Member** | Belongs to the organization but only sees applications their teams have access to. No organization admin capabilities.                                        |

<Note>
  Admins automatically have access to every application in the organization. No team assignment needed.
</Note>

## Application access

Applications are private to the teams that are assigned to them.

There is no separate read-only role inside an application:

* If a team has access to an app, its members can use that app fully.
* If a team does not have access, its members do not see that app at all.

## Teams

Teams are the glue between members and applications. Instead of granting access user by user, you assign it at the team level.

Here's how it works:

1. A user joins the organization
2. They're added to one or more teams
3. Teams are assigned to specific applications
4. The user inherits access through their teams

## Default team

Every new organization gets a default team called **General**.

* The organization creator is added to `General`
* The first application created in the organization is shared with `General`
* Applications created after that are not shared automatically

This keeps onboarding simple without making every new app visible by default.

### Example

Say you have three teams and three apps:

| Team    | Application     |
| ------- | --------------- |
| Backend | api-prod        |
| DevOps  | api-prod        |
| DevOps  | internal-tools  |
| Finance | billing-service |

This means:

* Backend engineers can operate `api-prod`
* DevOps can operate both `api-prod` and `internal-tools`
* Finance stakeholders can access `billing-service`

## Invitations

When inviting someone to your organization, you pick their organization role first: `Admin` or `Member`.

If you invite them as a **Member**, you can assign them to teams right away. They'll join with the correct application access from day one. No temporary over-permissioning.

If you invite them as an **Admin**, they automatically have access to the whole organization and every application.