Organizations
An organization is the top-level tenant: every agent, workspace, member, role, and API key belongs to exactly one. Cross-organization access is refused by the API even for a caller holding the right permission in their own organization.
Every deployment has one
A default organization is created by the database migration on first install, and every agent and user is attached to it. A single-tenant deployment therefore needs nothing on this page: it already has an organization, and there is no screen to visit.
The default organization’s display name can be set from the deployment with DEFAULT_ORG_NAME, applied idempotently on every boot — so a single-tenant install can carry its own branding without any per-instance code.
Listing the organizations you belong to requires org:read and is always available.
Managing more than one
Enterprise feature. Creating, renaming, and deleting organizations is available on Polyant Enterprise deployments.
Unlike the other enterprise features, multi-organization is not unlocked by the build alone: an enterprise deployment is locked to a single organization until EE_MULTI_ORG_ENABLED=true is set. Until then the management routes stay gated off and gateway-authenticated identities are bound to the default organization.
With it enabled, the Organizations screen (/organizations) appears in the sidebar for an operator with org:write. Each route is gated on both the permission and the feature — the permission alone is not enough, and the request is refused outright when the feature is off.
From it, an Owner can:
- Create an organization (slug + name).
- Rename one.
- Delete one. This removes the tenant and everything scoped to it; there is no undo.
Only Owners hold org:write. An Admin — who can administer members, workspaces, and agents — deliberately cannot create or delete the organization they work in.
What is scoped to an organization
| Scoped per organization | Shared platform-wide |
|---|---|
| Agents, conversations, memories, knowledge | Local sign-in accounts (Settings → Users) |
| Workspaces and their bindings | The engine’s environment configuration |
| Members and their roles | The tool registry and installed plugins |
| Custom roles | Which enterprise features are licensed |
| Management API keys | |
| The governance policy catalogue | |
| The authorization audit trail |
See also
- Workspaces — subdividing an organization.
- Members — who belongs to it and with which role.
- Roles and permissions — what
org:writeactually grants.