> ## Documentation Index > Fetch the complete documentation index at: https://docs.dfns.co/llms.txt > Use this file to discover all available pages before exploring further. # Tenants > A tenant groups your DFNS organizations under one umbrella, to separate environments, business lines, or regions, or to give each client of your platform its own organization. Tenant users work across organizations, while org users, wallets, vaults, policies, and org permissions stay isolated in each organization. > [!NOTE] > > Multi-organization management is available on demand. Contact our [Support Team](https://support.dfns.co) to enable it for your account. ## The model ### At tenant level The tenant holds what spans your [organizations](https://docs.dfns.co/core-concepts/organizations.md), including: * **Tenant users**: your team members who work across organizations. Each tenant user has one identity and one set of credentials for the tenant and for every organization they are invited to. * **Tenant permissions**: what each tenant user can do at tenant level, such as creating organizations or managing other tenant users. See [Tenant permissions](https://docs.dfns.co/core-concepts/roles-and-permissions.md#tenant-roles). * **Key stores**: the MPC clusters, HSMs, and offline signers DFNS assigns to your tenant. Each organization uses the key stores the tenant assigns to it. See [Organizations and key stores](https://docs.dfns.co/advanced/deployment-models#organizations-and-key-stores). * **Plan limits**: the limits of your plan, such as the number of tenant users and org users, keys, policies, organizations, and monthly signatures, apply to the tenant as a whole. Usage in every organization counts toward the same limit. Tenant settings and billing are also managed at tenant level. ### What lives in one organization * **Org users, end users, and service accounts**. Each belongs to exactly one organization and can only ever act inside it. The same person needs a separate identity, with new credentials, to act in another organization as an org user. * **Org permissions, wallets, vaults, and policies**. They always belong to one organization and are never shared with another. * **Webhooks and integrations**, such as KYT, Travel Rule, and exchanges. * **The audit trail** of everything that happens in the organization. **Organizations are entirely segregated from one another.** Nothing inside one organization is visible from another organization, including from a sibling organization in the same tenant. The tenant cannot override an organization's policies: approvals are always decided inside the organization. ### Who can be where | User type | Tenant | Organizations | | :- | :- | :- | | Tenant user | Yes | Only the organizations they are invited to | | Org user | No | Individual organizations, without seeing the tenant level. The same email can be an org user in several organizations, as a separate identity in each | | End user | No | One organization, without knowing it. End users live in your application and never interact with DFNS directly | ## Which type of user to create * **Tenant users** for your own team. Only tenant users can be invited into several organizations, and they keep the same identity and credentials in each. With a tenant, most teams need only tenant users. * **Org users** when you want strict segregation, for example for a client's staff in their own organization. An org user is created in one organization and registers their own credentials there. That identity and those credentials can never act in another organization. * **End users** for your customers who sign for their own wallets. See [Delegated wallets](https://docs.dfns.co/advanced/delegated-wallets.md). ## Tenant permissions and org permissions Tenant permissions and org permissions are separate: * **Tenant permissions** apply at tenant level only, for example to manage tenant users and organizations. They give no access inside an organization. * **Org permissions** apply inside one organization. A tenant user holds a separate set in each organization they are invited to: org permissions in one organization grant nothing in another. Every new org user, tenant user, and service account starts in an organization with no org permissions. Someone in that organization who can assign permissions grants them. End users are the exception: they receive the [default end-user role](https://docs.dfns.co/core-concepts/roles-and-permissions.md#manageddefaultenduseraccess). A tenant user who creates an organization becomes its first org admin. When a tenant user is removed from an organization, they lose all their org permissions there. If they are invited again later, they start again with none. To invite tenant users into organizations and grant their org permissions, see [Work across organizations](https://docs.dfns.co/guides/work-across-organizations.md) in the dashboard, or [Manage organizations and tenant users](https://docs.dfns.co/guides/developers/manage-organizations.md) with the API. ## Multi-organization setups These setups cover the most common reasons to run several organizations. You can combine them, for example separate environments for each business line. ### One tenant, separate environments Development, UAT, and production run as isolated organizations under one tenant. Your platform team manages all three with one set of tenant users invited into each, without needing any org users. Wallets, policies, and data stay separate between environments. * **Tenant**: your platform and operations teams, with full access to every environment. * **Each organization**: environment-specific service accounts (CI, production jobs), plus org users only for people you want to confine to one environment. ### Separate teams and governance per organization One organization per client, region, or business line, each with its own admins, policies, and approvers. For example, a bank with one organization per jurisdiction, an asset manager with one organization per segregated mandate, or a group that keeps an acquired business in its own organization. A central tenant team keeps oversight, while day-to-day control stays in each organization. * **Tenant**: a small central team, such as compliance with read-only access, for group-wide visibility. * **Each organization**: its own admins and team, who run that region, client, or business line with their own policies and approvers. Grant a tenant user full access to an organization only where central operation is needed. ### B2B2B: end-user wallets and client organizations As a platform, you serve each client at the level they need: * **End-user wallets** for clients who only need a wallet. Each client is an end user in your organization and the sole signer of their wallets. See [Delegated wallets](https://docs.dfns.co/advanced/delegated-wallets.md). * **Client organizations** for larger or more complex clients. You create an organization for the client under your tenant. Their people are org users in that organization, with their own org permissions, policies, and approvals. You can offer both from the same tenant. | | End-user wallet | Client organization | | :- | :- | :- | | Where the client lives | An end user in your organization | Their own organization under your tenant | | Client's identities | One end user, the sole signer | As many org users and service accounts as they need | | Policies and approvals | Not applied: the end user signs alone | The full policy engine: approvals, spending limits, and more | | Permissions | Set by you: the [default end-user role](https://docs.dfns.co/core-concepts/roles-and-permissions.md#manageddefaultenduseraccess), which you can edit, or your own roles. End users cannot change them | Their own org permissions, managed by the client's admins | | Scope | Wallets | Everything an organization holds: wallets, vaults, webhooks, integrations, and its own audit trail | | Your access | You cannot sign for the client | Set per client: full, read-only, or none | For example, a custody provider serving retail customers with end-user wallets and client banks with client organizations, or a payment platform serving small merchants and enterprise clients. #### Client organizations You set your access through the org permissions you give your tenant users in each client organization: | Access | Org permissions for your tenant users | Typical use | | :- | :- | :- | | Full | `ManagedFullAdminAccess` | You co-manage the organization with the client | | Read-only | A read-only role, such as one built from the Auditor template | You monitor and support the client | | None | None, or not invited | You hand the organization over after setting it up | To onboard your clients' org users from your own application, without registration emails from DFNS, use delegated registration for org users. It is enabled on demand, for the whole tenant. See [Onboard client org users with delegated registration](https://docs.dfns.co/guides/developers/manage-organizations.md#onboard-client-org-users-with-delegated-registration). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.