Organisations

An organisation is FeatureGate's customer boundary. It owns projects, roles, billing, management keys, operational defaults, activity history, and the tag vocabulary shared by its flags.

Use another organisation when the people who administer access, pay the bill, or own audit history must differ. Prefer projects and environments for technical separation inside one customer boundary.

Personal and team organisations

A personal organisation has one fixed owner and suits individual work. A team organisation supports accepted members, role assignment, invitations, ownership transfer, and seat-based Team billing.

Situation	Recommended boundary
One person evaluating a product privately	Personal organisation
A company team sharing projects and billing	Team organisation
Two products with the same administrators and bill	Separate projects in one organisation
A client requiring isolated membership and audit ownership	Separate organisation
Development and production for one application	Environments in one project

Do not create an organisation merely to represent development and production. Those are runtime boundaries and belong in project environments.

Create and administer an organisation

Every account begins with a personal organisation. Create a paid team organisation from the organisation switcher. The flow begins Team checkout with a card-required trial and three-seat minimum.

An eligible personal owner can instead promote an existing personal organisation. Its projects, flags, keys, settings, usage, and activity remain attached while it becomes a team.

After promotion, FeatureGate creates a new Hobby personal organisation for the owner. A team organisation cannot be converted back to personal.

Owners and admins manage identity, members, defaults, access keys, and billing. Members build inside projects. Viewers have non-secret read-only access.

Review the maintained permission matrix before assigning broad access. Runtime and client keys do not inherit a person's role; they use their own scopes.

Ownership and credential boundaries

Runtime and client keys belong to an organisation through their project. Management keys can see only resources permitted by their organisation binding and scopes.

If an owner transfers a project, active runtime and client keys follow it. Project-scoped management keys in the source organisation are revoked because their authority must not cross silently.

Historical activity and API usage attribution remain with the source organisation. A transfer changes current ownership; it does not rewrite the historic record.

Account preferences remain separate. Passkeys, sessions, theme, timezone, Gravatar preference, and optional email preferences belong to the person across every organisation.

Lifecycle

An active organisation serves normally. Scheduled closure remains operational until the export window begins. During the export window and deletion-pending state, ordinary console routes and API keys block.

The compatibility API error is WORKSPACE_OFFBOARDING. Rotating a key will not resolve it. An owner must review the offboarding page or reactivate the organisation while that action remains available.

Failure and recovery cases

• If a desired slug is unavailable, choose another lowercase alphanumeric-and-dash identifier.
• If a member cannot see a project, confirm membership and role in the owning organisation.
• If billing ownership must change, transfer ownership before changing the outgoing owner's access.
• If an API reports offboarding, inspect organisation lifecycle rather than credential scopes.

Related pages: Invite and manage a team, Plans and billing, and Organisation closure.