> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://docs.prividium.com/api/mcp` to find what you need.
>
> **Have feedback?** Use `submit_feedback` on the same MCP server.

Organizations group users under a shared context with default roles. M2M applications can be linked to organizations to
programmatically manage users and make RPC calls on their behalf.

:::note
> The behaviour below describes a zone with `MULTI_ORG_ENABLED` on. With it off, organizations only group users for M2M
> access: an organization cannot own roles, so its members hold zone-level roles and are managed from the ordinary
> [Users](/configuring/users/managing-users) and [Roles](/configuring/users/roles) pages like any other user.
:::

***

### 1. Open the Organizations page

1. Go to the **Admin Dashboard**.
2. Select **Organizations** from the sidebar.
3. Review the list of organizations with their names and default roles.

### 2. Create an organization

1. Click **Add Organization**.
2. Fill in the details:
   * **Organization Name** (required): A descriptive name for the organization.
3. Click **Create Organization**.

Default roles are configured after the organization exists (its roles must be created first). See
[Edit an organization](#3-edit-an-organization) and [Default roles](#5-default-roles).

### 3. Edit an organization

1. Click the organization row in the list.
2. Click **Edit Organization**.
3. Update the name or default roles.
4. Click **Save Changes**.

:::info
Changing default roles does not affect users already in the organization. Default roles are only assigned when a user
is created within the organization (see [Default roles](#5-default-roles) below).
:::

### 4. Delete an organization

1. Open the organization by clicking its row.
2. Click **Delete Organization**.
3. Confirm the deletion.

:::info
Deleting an organization removes the organization record. This action cannot be undone. Member sessions and
organization-owned API keys are revoked, and members' wallet addresses are released.
:::

### 5. Default roles

Default roles define which roles are automatically assigned to users **created within** the organization. This applies
when an M2M application creates a user through the `org_users_manage` permission.

Only the organization's own roles are eligible as default roles; zone-level roles and the organization's Admin role
cannot be selected. Create the organization's roles on the [Roles](/configuring/users/roles) page while managing the
organization, then select them when editing the organization. With `MULTI_ORG_ENABLED` off, zone-level roles are
selected instead, since an organization cannot own roles.

Adding an existing user to an organization does **not** assign default roles to them.

### 6. Manage organization members

#### View users

1. Open an organization by clicking its row.
2. The organization detail page lists all users belonging to the organization.

#### Add an existing user

1. On the organization detail page, click **Add User**.
2. In the modal, search for the user by name.
3. Select the user to add. Users already in another organization are shown as unavailable.

:::note
A user can only belong to one organization at a time, and can only be added while they hold no roles (roles are scoped
to the organization, so assign them after adding the user). Adding a user that already belongs to another organization
or still holds roles will fail. With `MULTI_ORG_ENABLED` off, a user keeps their zone-level roles when added.
:::

#### Remove a user

1. Find the user in the organization's user list.
2. Click **Remove**.
3. Confirm the action.

Removing a user from an organization clears their organization membership and their organization-scoped roles (including
the organization Admin role). The user account itself is not deleted, and they can be added again later.

### 7. Organization contracts

Creating a contract from the zone-wide Contracts page registers it at zone scope, even when the operator belongs to an
organization. To assign a contract to an organization, switch to that organization's context before creating it.

An organization owns the contracts registered under it, and its administrators manage those contracts and their
permissions without seeing the rest of the zone. Registration is subject to the following rules:

* Kernel and protocol predeploy addresses from `0x0000000000000000000000000000000000008000` through
  `0x000000000000000000000000000000000001ffff` belong at zone scope. Organizations cannot register them or move a
  contract to them, even through a zone operator. System contract permissions remain a zone-operator responsibility.
* The contract must already be deployed. Prividium™ rejects an address that holds no code, because registering an
  address is what grants the organization's roles access to it. This applies to everyone, operators included.
* **Organization administrators only:** the address must have a deployment record in Prividium™. The deployer must be
  the administrator registering it or a member of the same organization, so an address another organization deployed
  cannot be claimed. A zone operator is not subject to this rule - they curate the zone's callable surface and may
  assign non-reserved contracts to an organization.
* Factory, CREATE2, and externally deployed contracts without a deployment record require explicit assignment by a zone
  operator. Missing or failed deployment records do not prove ownership.
* Changing a registered contract's address is subject to the same rules, since the function and event permissions move
  to the new address.
* [Selective disclosure](/configuring/contracts/selective-disclosure) cannot be enabled from the organization's routes or views. It stays
  a zone-operator decision; an operator can set it for an organization's contract from the zone-wide Contracts page, and
  later organization-side edits leave that setting untouched.

The reserved-address migration automatically removes any organization claims in this range and their attached
permissions and disclosure settings. It preserves zone-owned contracts and non-reserved application registrations,
including operator-assigned factory deployments and interop imports.

### 8. What an organization admin may delegate

An organization admin manages their own organization, not the zone. The roles they create can carry only the
organization-scoped system permissions — `org_users_manage`, `org_wallets_manage` and `org_rpc_access` — and the same
ceiling applies when they **assign** an existing role to a member: an organization role carrying a zone permission such
as **Contract Deployment** is refused, even though the role is listed on the organization's Roles page. A zone operator
can still make that assignment. The ceiling applies only to roles being added: a member's already-held roles stay intact
through any edit. Delegating the organization's own Admin role to another member stays allowed, since it grants nothing
the organization admin does not already hold.

Contract configuration is bounded the same way. Function permissions an organization admin creates are always scoped to
their organization, and they cannot set the **Umbrella** flag that relaxes function-permission checks on internal calls.
Published policy rules still apply to the inner calls that policy governs. Registering an organization-owned contract
against a zone template that uses Umbrella is refused for the same reason. If a zone operator later adds Umbrella to a
template an organization contract already uses, organization-side edits require moving that contract off the template.

### 9. Linking M2M applications

M2M applications are linked to organizations through the M2M application configuration. Once linked, an M2M app with the
appropriate system permissions can create users, manage wallets, and make RPC calls on behalf of organization users.

For details on M2M application setup and permissions, see
[M2M Applications](/configuring/applications/m2m-applications#organization-user-management).

### 10. Configure wallet login (SIWE)

Each organization can enable or disable wallet-based login independently. When enabled, the wallet login option appears
on the organization's User Panel login page.

1. Open the organization by clicking its row.
2. Select the **Wallet Login (SIWE)** tab.
3. Check **Enable SIWE wallet login for this organization**.
4. Optionally add extra allowed domains (one per line). The host of the organization's User Panel URL is accepted
   automatically.
5. Click **Save**.

:::note
The wallet login tab is only available when SIWE is configured globally on the Permissions API. See
[Configure Auth](/configuring/users/authentication) for global setup.
:::

### 11. Configure branding

Each organization can carry its own brand identity. When set, the organization's brand name, logo, and primary color
replace the zone defaults on its User Panel. Branding is saved as a complete unit: all three fields together, so a
partially filled form is rejected.

1. Open the organization by clicking its row.
2. Select the **Branding** tab.
3. Fill in all three fields. See [Per-Organization Branding](/configuring/chain/branding#5-per-organization-branding)
   for the field constraints and logo hosting rules. The **Preview** panel shows how the values will render.
4. Click **Save**.

To revert to zone branding, click **Remove branding**.

***

### Tips

* Organization default roles must be the organization's own roles; create them on the
  [Roles](/configuring/users/roles) page while managing the organization.
* Use the [Users](/configuring/users/managing-users) page to view a user's current organization membership.