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

# Organizations

> Organize your tenant by separating between organizations

Organizations provide logical separation of infrastructure within your 2501 account. They enable multi-tenancy, allowing you to partition resources, agents, and operations based on your operational structure.

## What is an Organization?

An organization is a scoping boundary that groups related infrastructure and operations. All operational resources are associated with an organization, providing isolation and access control within your account.

## Organization Structure

Your tenant is the isolation boundary: nothing is ever visible across tenants, whatever a user's role or scope. Inside the tenant, every resource is scoped in exactly one of three ways.

### Organization-scoped resources

These resources always belong to one organization and cannot be made tenant-wide:

* **[Hosts](/0.18/core-concepts/hosts)**: target systems, including their gMSA configuration
* **[Agents](/0.18/core-concepts/agents)**: each agent belongs to its host's organization
* **[Tasks](/0.18/core-concepts/tasks)** and **[Jobs](/0.18/core-concepts/jobs)**: execution history
* **[Job Schedules](/0.18/core-concepts/job-schedules)**: recurring and deferred work
* **[Tickets](/0.18/core-concepts/tickets)** and their comments
* **Chats** and their messages
* **[Gateways](/0.18/core-concepts/gateways)**: ticket routing integrations
* **[Webhooks](/0.18/configure/webhooks)**: outbound notifications
* **[Network Discovery](/0.18/configure/discovery)**: scans and the nodes they find
* **[Knowledge](/0.18/configure/knowledge)**: uploaded documents and the host facts extracted from them

### Shared resources

These resources can be scoped to a specific organization or left unscoped, which makes them available across all organizations in your tenant:

* **[Credentials](/0.18/configure/credentials)**: authentication secrets
* **[Specialties](/0.18/configure/specialties)**: agent domain configurations
* **[Operational Rules](/0.18/configure/operational-rules)**: mandatory procedures
* **[Blacklists](/0.18/configure/blacklist)**: prohibited commands
* **[Plugins](/0.18/configure/plugins)**: MCP integrations and tools
* **[Providers](/0.18/configure/providers)**: LLM endpoints, tenant-wide unless **Scoped to current organization** is ticked when creating one. [Models](/0.18/configure/models) belong to a provider and take its scope: an organization-scoped provider's models are available only to that organization
* **API keys**: scope is chosen when the key is created and cannot be changed afterwards
* **Verifier exceptions**: one tenant default plus one override per organization, managed by administrators

When a shared resource is organization-scoped, only agents and operations within that organization can use it. When unscoped, it is available to every organization. An organization can also hold a credential with the same name as a tenant-wide one: the organization's own is used first and the tenant-wide one is the fallback, so a shared default can be overridden per organization.

<Note>
  Creating or editing a tenant-wide shared resource requires [tenant-level access](/0.18/configure/users). Users restricted to specific organizations can read tenant-wide resources but only write within their own organizations. Tenant-wide providers and the model catalog are further limited to tenant-level administrators. Verifier exceptions are the one exception to the read rule: an organization-restricted administrator sees and edits only their organization's override, not the tenant default it replaces.
</Note>

### Tenant-level resources

These have no organization at all - they describe the tenant itself:

* **Organizations** and **[Users](/0.18/configure/users)**, including which organizations each user belongs to
* **[Licensing](/0.18/configure/licensing)**: plan and usage limits

## Creating Organizations

Organizations can be created from **Command Center > Settings > Organizations**. Click **New Organization**, enter a name, and save.

For the initial organizations at the first deployment, edit `organization.yaml` before deploying. See [Users & Organizations](/0.18/deployment/users-organizations) for the bootstrap workflow.

## Archiving Organizations

A tenant administrator can archive an organization; archiving keeps all of its data. In **Settings → Organizations**, a tenant administrator clicks **Archive** on an organization. An archived organization:

* is hidden, and its members and organization API keys lose access to it
* is read-only: its resources cannot be changed until it is unarchived
* stops its running jobs and tasks
* stops receiving tickets and alerts from its gateways and webhooks
* pauses its schedules, which resume when it is unarchived

Nothing is deleted. An archived organization's name is free for a new organization; if one takes it, rename one of the two before unarchiving. Archived organizations are listed under **Archived organizations**, where **Unarchive** restores them. A tenant always keeps at least one active organization.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.