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

# Team management

> Organizations let teams share runners, projects, and secrets with role-based access control.

Organizations provide a shared space for development resources. Administrators can manage projects, environments, runners, and member access. For personal use, you can create an organization for yourself.

Think of an organization as the administrative and security boundary for Ona. Projects, runners, secrets, login settings, and policies all live inside an organization.

## What organizations contain

| Resource                                                    | Description                                                                 |
| ----------------------------------------------------------- | --------------------------------------------------------------------------- |
| [Projects](/ona/projects/overview)                          | Environment configurations linked to repositories                           |
| [Runners](/ona/runners/overview)                            | Infrastructure for running environments                                     |
| [Members](/ona/organizations/manage-members)                | Users with role-based permissions                                           |
| [Groups](/ona/organizations/groups)                         | Collections of members for access management                                |
| [Teams](/ona/organizations/teams)                           | Organizational units used for usage attribution and per-team credit budgets |
| [Organization roles](/ona/organizations/organization-roles) | Delegated admin roles for runners, projects, groups, and automations        |
| [Secrets](/ona/configuration/secrets/overview)              | Shared credentials and API keys                                             |
| [Policies](/ona/organizations/policies/overview)            | Organization-wide settings and restrictions                                 |

## Groups vs. teams

[Groups](/ona/organizations/groups) and [teams](/ona/organizations/teams) are two ways to organize people in an organization. They solve different problems and most organizations use both.

* **Use a group** to answer *"who can use this runner?"* or *"who can edit this project?"*
* **Use a team** to answer *"who's on the Backend team?"* and *"how much did Backend spend this month?"*

|                                  | **Groups**                                                     | **Teams**                                                 |
| -------------------------------- | -------------------------------------------------------------- | --------------------------------------------------------- |
| **Purpose**                      | Access control for projects, runners, and automations          | Organizational reporting and cost management              |
| **Membership**                   | A member can belong to **many groups**                         | A member belongs to **at most one team** per organization |
| **Provisioning**                 | Managed in Ona, or synced from your identity provider via SCIM | Managed in Ona                                            |
| **Visibility**                   | Group membership is visible to organization members            | All organization members can see all teams                |
| **Affects billing reporting?**   | No                                                             | Yes, usage is rolled up per team                          |
| **Affects access to resources?** | Yes                                                            | No                                                        |

See [Manage groups](/ona/organizations/groups) and [Manage teams](/ona/organizations/teams) for the details.

## Isolation

Organizations are hard boundaries. Resources cannot be shared or transferred between them. Each runner, project, and environment belongs to exactly one organization.

Users can be members of multiple organizations but must switch between them explicitly.

## What admins usually manage

Organization admins usually own:

* who can join and how they authenticate
* which runners and projects are available
* how resources are shared across teams
* which guardrails and policies apply by default
* what secrets and service accounts shared workflows can use

## Common operating model

For many teams, the pattern looks like this:

1. create or join the organization
2. connect identity and invite members
3. add runners or enable Ona Cloud regions
4. create shared projects
5. apply policies, secrets, and guardrails as the team grows

## Next steps

* [Create an organization](/ona/organizations/create-organization)
* [Manage organization](/ona/organizations/manage-organization)
* [Manage members](/ona/organizations/manage-members)
* [Configure policies](/ona/organizations/policies/overview)
* [Sharing resources](/ona/organizations/sharing-resources)