Organization roles and permissions.
OneOrg uses system roles and custom roles to control what members can manage, which tools they can access, and which organization settings they can change.
Role model
Roles are managed from the organization settings area. Every member has a system role such as viewer, member, admin, or owner. These roles give teams a simple default structure: viewers can observe, members can participate, admins can manage most of the workspace, and owners retain top-level control.
For teams that need more precise access, admins can create custom roles. A custom role can include named permissions for workspace management, settings, analytics, members, roles, projects, and related admin tasks. It can also limit access to MCP servers, individual MCP tools, and dashboard widget types.
This matters because OneOrg includes both normal collaboration features and AI/tooling features. A user who can participate in projects should not automatically be able to manage provider keys, expose new MCP tools, or change organization-wide model policy. Roles let admins separate participation from governance.
Owner remains the highest-trust role. Use custom roles to narrow access for specialized teams, not to weaken owner-level control.
A clean role design starts from responsibility. Decide what the person needs to manage, what they only need to view, and which AI or tool surfaces they should never touch.
Review roles whenever the organization adds a new governed capability. Provider keys, MCP tools, integrations, dashboards, budgets, and member management are not the same kind of access as normal project participation. A good role model separates people who do the work from people who govern the workspace. Start with system roles, then create custom roles only where a real boundary exists. Avoid custom roles named after individuals. Name them after responsibilities, such as Finance reviewer or MCP tool admin, so the role still makes sense when people change teams. Remove unused custom roles during access reviews.
Access review pattern
Use system roles when the default hierarchy is enough: viewer, member, admin, owner. Use custom roles when a team needs scoped access, such as a read-only analyst, limited integration manager, MCP tool user, or dashboard designer with restricted widget types.
Do not create custom roles as a substitute for clear operational ownership. If someone is responsible for organization-wide settings, they need a role that matches that responsibility. If they only need one capability, limit the role to that capability.