Monocle uses a two-layer permission system: organization roles for managing the workspace, and team-based project access for deciding who can use each project.
The key idea: being part of an organization doesn't automatically grant access to every project. 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 projects. Assign team access to projects. Has access to all projects. |
| Member | Belongs to the organization but only sees projects their teams have access to. No organization admin capabilities. |
Admins automatically have access to every project in the organization. No team assignment needed.
Project access
Projects are private to the teams that are assigned to them.
There is no separate read-only role inside a project:
- If a team has access to a project, its members can use that project fully.
- If a team does not have access, its members do not see that project at all.
Teams
Teams are the glue between members and projects. Instead of granting access user by user, you assign it at the team level.
Here's how it works:
- A user joins the organization
- They're added to one or more teams
- Teams are assigned to specific projects
- 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 project created in the organization is shared with
General - Projects created after that are not shared automatically
This keeps onboarding simple without making every new project visible by default.
Example
Say you have three teams and three apps:
| Team | Project |
|---|---|
| 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-prodandinternal-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 project 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 project.