---
title: Organizations and sectors
description: The organization-based multi-tenant model behind the developer
  portal — how organizations own applications and sectors, the
  Viewer/Admin/Owner role hierarchy, and how resources are retired.
editUrl: true
head: []
template: doc
sidebar:
  order: 3
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

When you build on Sudomimus, your resources live inside an **organization**. The developer portal at [`with.sudomimus.com`](https://with.sudomimus.com) is organization-based and multi-tenant: an organization owns your applications, sectors, adopted domains, and federation connectors, and you collaborate with teammates by giving them a role in that organization. This page defines those pieces and how they relate.

```
Account ──member-of──> Organization ──owns──> Application
                            │                      (one per sector)
                            └────────owns────────> Sector
```

## Organizations

An **organization** is the multi-tenant container that owns everything you create as a developer — applications, sectors, [adopted domains](/en-us/domains-federation/overview/), and [federation connectors](/en-us/domains-federation/federation-connectors/).

- You become a developer simply by **creating an organization** from the With portal; that makes you its first **Owner**. "Developer" is not a separate kind of account — it is a capability any Sudomimus user picks up by belonging to an organization.
- Every account holder always has the personal **Account** surface (Profile, sign-in methods, data sharing). The **Developer** surface — Organizations, Applications, Sectors — simply lists the organizations you belong to. Belonging to none is a normal state, not an error.
- An organization has limits on how many applications and sectors it can hold, and each account has a limit on how many organizations it can own.

## Applications

An **application** is a single integration — a web app, game, CLI, or OIDC relying party. It carries a permanent [`applicationAnchor`](/en-us/connect/three-key-model/), its signing and client-auth keys, and the [three layers of rules](/en-us/application-rules/overview/) that decide who can log in and how. Every application belongs to exactly one organization and exactly one sector.

## Sectors

A **sector** is the identity-isolation boundary. Applications in the same sector see the **same** opaque identifier for a given user; applications in different sectors see **unrelated** identifiers for the same person. By default each application gets its own fresh sector (maximum isolation); you opt in to shared identity by placing two applications in one sector.

The privacy contract behind sectors — the sector subject, account alias, and why the raw account ID never leaves the system — is covered in [Privacy & pairwise identity](/en-us/concepts/pairwise-identity/).

## Roles and membership

Collaboration is managed at the **organization** level — there is no per-application or per-sector membership. Each member holds one role, and the three roles form a rank:

**Viewer < Admin < Owner**

| What you can do | Minimum role |
|---|---|
| View applications, sectors, rules, and organization settings | **Viewer** |
| Create and edit applications, configure rules, rotate keys, set the [claim policy](/en-us/concepts/identity-claims/) | **Admin** |
| Manage members — invite, change a role, remove | **Owner** |
| Retire (disable) an application, a sector, or the organization | **Sole Owner** |

Members are invited by their **account alias** (the user-visible handle, never the internal account ID). An organization can have more than one Owner; the portal refuses to remove or demote the **last** remaining Owner, so a developer cannot accidentally orphan their own organization.

## Retiring resources

There is **no hard delete** on the developer surface. To take a resource out of service you **retire** it by disabling it:

- Retiring an **application** immediately makes every login to it fail, but already-issued tokens keep working until they expire.
- Retiring a **sector** requires that every application in it is already disabled.
- Retiring an **organization** requires that every application and sector it owns is already disabled. A retired organization is **frozen** — no member, rename, or create operation works on it until you re-enable it.

Each of these retire operations requires you to be the organization's **sole** Owner, so one co-owner cannot unilaterally pull a shared resource out from under the others.

## How this interacts with account deletion

Because retiring is the only way to wind a resource down, account deletion has a guard rail: you **cannot erase your account while you are the sole Owner of an organization that still holds a live resource** (an enabled application or a non-disabled sector). Retire those first. A co-owned organization never blocks deletion — another Owner remains. See [Account deletion](/en-us/guides/account-deletion/) for the full erasure flow.

## Where this lives

Everything above is managed in the With portal at [`with.sudomimus.com`](https://with.sudomimus.com). A resource that belongs to no organization is platform-managed and never appears in a developer's dashboard.