Role-based access at organization, folder, and project scope.
IOModel authorization is role-based at three scopes: organization, folder, and project. Assign the minimum role required for each person’s responsibilities. The same user may hold different roles in different places.
Enterprise SSO and centralized identity: Roles and Permissions.
Organization roles
Configured on the org Members tab:
| Role | Capability |
|---|---|
org_owner | Full org control — members, folders, projects, billing |
org_admin | Operational admin — members, folders, projects |
org_member | Access only via folder or project membership |
org_owner and org_admin bypass project-level checks and effectively hold owner access on every project in the organization — even when explicitly assigned viewer on a project. Limit org admin assignments.
| Capability | org_owner / org_admin | org_member |
|---|---|---|
| Create, import, or clone projects | Yes (org root; folder admin inside folders) | By folder/project role |
| See every project on Projects tab | Yes | Only projects with a grant |
| Open and edit project content | Yes — effective role owner | By assigned role |
| Project Settings (gear on project row) | Yes — any project | Project admin or higher |
Folder and project roles
Configured in Folder settings or Project settings → Members:
| Role | Capability |
|---|---|
owner | Full control including delete |
admin | Members, settings, publish, GitHub |
editor | Model, specs, branches, commits |
viewer | Read-only — no edits, commits, or branch management UI |
For org_member, effective project role is the highest role from direct project membership, inherited folder grants, and group grants on that project.
Folder membership inherits to contained projects. Use project-level grants only for exceptions — single-project access or elevated/different role.
Viewers see specs and model but cannot change content, commit, or use branch controls (switcher actions, Changes branch list, private-branch links). Editors and above manage branches subject to plan limits.
Users vs groups
Folder or project Members → Add → user → role.
Suitable for external collaborators and small teams.
Procedure: grant a squad folder access
Example — squad Edge needs editor on all projects under folder examples:
Create group
Groups → New group → edge-team → add members.
Assign folder role
Folder examples → Folder settings → Members → Add → edge-team → editor.
Verify inheritance
Open a project under examples. Project settings → Members should list edge-team with source examples.
Restrict readers
Stakeholders who read only: viewer on specific projects, not folder-wide editor.
Least privilege
Reserve owner and admin for access and lifecycle management. Most
contributors need editor; most reviewers need viewer.
Missing New Project, edit controls, or branch switcher usually indicates viewer access. Request elevation from a folder or project admin.
Last updated on