Skip to content
Prividium

Manage Organizations

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.

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 and 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.

4. Delete an organization

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

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 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.

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 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 makes the transaction-policy service stop checking a transaction's internal calls. Registering an organization-owned contract against a zone template that uses Umbrella is refused for the same reason, and if a zone operator later adds Umbrella to a template an organization contract already uses, every organization-side edit of that contract is refused until the contract is moved 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.

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.

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 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 page while managing the organization.
  • Use the Users page to view a user's current organization membership.