> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/general/tenants.md).

# Tenants

A tenant is a deployment of akenza. It holds organizations, and offers integrations and device type libraries to all of them.

<div align="left"><figure><img src="https://2165942204-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MMKXTFIN5ZlLOjBlfC4%2Fuploads%2F6hIEzbQsA3N0eEgc2BBF%2Fenterprise.png?alt=media&amp;token=a2ef5bf8-1e13-4c49-bf5e-2d00005cbd3c" alt="" width="103"><figcaption></figcaption></figure></div>

A **tenant** is a deployment of akenza. Every instance of the platform is one tenant: the akenza public cloud is a single tenant shared by everyone who uses it, and every Enterprise deployment is a tenant of its own.

Every organization therefore belongs to exactly one tenant, which makes the tenant the outermost level of the hierarchy:

* **Tenant**
* [Organization](/general/organization-context.md)
* [Workspace](/general/workspace-context.md)

Running your own tenant is an akenza Enterprise arrangement. It gives you a deployment separate from the public cloud, and the deployment-wide settings described below. Configure your own Connectivity-as-a-Service integrations, connect your custom device type library, brand the whole deployment as your own, and plug in your own identity provider.

{% content-ref url="/pages/MBnzovez3BvULUelZVEB" %}
[Deployment](/general/tenants/deployment.md)
{% endcontent-ref %}

## Tenant roles

Two roles can be assigned at tenant level, and both span every organization on the tenant:

<table><thead><tr><th width="190">Role</th><th>Access</th></tr></thead><tbody><tr><td><strong>Tenant admin</strong></td><td>Read-only across all organizations, and may add themselves to any organization in order to work in it.</td></tr><tr><td><strong>Tenant viewer</strong></td><td>Read-only across all organizations.</td></tr></tbody></table>

{% hint style="info" %}
A tenant admin does **not** hold write access to organizations by default. Until they add themselves to an organization, their access is read-only, exactly like a tenant viewer. Adding themselves is the deliberate step that grants working access, and it puts them in that organization's user list like any other member.
{% endhint %}

Reaching every organization is what makes the role useful: a tenant administrator can track metrics across the whole deployment and provide support to any organization on it, without each one having to invite them first.

It also means the tenant level is not a silent master key. Someone with tenant admin rights can see the state of every organization, but has to join one before changing anything in it.

## Tenant integrations

A **tenant integration** is a [connectivity provider account](/device-management/your-data-flow/device-connector/lorawan/your-integration.md) set up once at tenant level and made available to **all organizations and their workspaces** on the tenant. This is how [Connectivity-as-a-Service](https://akenza.io/features/connectivity-as-a-service) is offered: connectivity is arranged once for the deployment, and every user on it can onboard devices without a contract of their own with the network provider.

When a data flow is created in any workspace, a device connector belonging to a tenant integration can be chosen alongside the workspace's own integrations. Nobody has to set up their own account with the provider first.

This is the arrangement to reach for when the same network serves many customers. A network operator or reseller running their own tenant connects their LoRaWAN network once, and every customer organization on that tenant can onboard devices onto it.

Tenant integrations are managed under **Tenant Management Settings**.

{% hint style="warning" %}
Deleting a tenant integration removes it from every organization and workspace that was using it. Check what depends on it before removing one.
{% endhint %}

## Device type libraries

[Device type libraries](/device-management/your-data-flow/device-type/library.md) are also managed at tenant level, and likewise apply to all organizations and workspaces on the tenant.

The **akenza default** library is listed here and can be enabled or disabled. Beyond it, custom device type libraries can be added, which makes your own device types available across every organization on the tenant. *Sync all libraries* refreshes them, picking up device types added since the last sync.

This is the place to put decoders you maintain yourself and want available everywhere, rather than creating the same [custom device type](/device-management/your-data-flow/device-type/device-type.md) separately in each organization.

## Tenant-wide white labeling

A tenant can be branded as a whole, so that the deployment presents itself as your product rather than akenza's. This covers the **theme** applied across the platform and the **email domain** that notifications and system mails are sent from, among other deployment-wide branding.

Combined with a [custom domain](/general/tenants/deployment.md#domains-and-certificates) for the deployment itself, the result carries your name from the address bar through to the mail that lands in someone's inbox.

{% hint style="info" %}
This is the deployment-wide layer of branding. An individual organization on the tenant can additionally brand itself with [white labeling](/device-management/managing-an-organization/general-settings/white-labeling.md), which is the right level when one reseller serves customers who each want their own look.
{% endhint %}

## Single sign-on

A custom **SSO integration** with your own identity provider is configured at tenant level and applies across the deployment. Users are routed to it automatically based on the domain of the email address they enter when signing in, so nobody has to know which provider to pick.

{% content-ref url="/pages/2jrXgXOtAj7QPMD4wIMc" %}
[Users](/general/users.md)
{% endcontent-ref %}

## What is managed at tenant level

<table><thead><tr><th width="230">Area</th><th>What it covers</th></tr></thead><tbody><tr><td><strong>Organizations</strong></td><td>Every organization on the tenant.</td></tr><tr><td><strong>Workspaces</strong></td><td>Every workspace, across all of those organizations.</td></tr><tr><td><strong>Devices</strong></td><td>Every device on the tenant.</td></tr><tr><td><strong>General settings</strong></td><td>Tenant integrations, device type libraries, white labeling, and single sign-on.</td></tr><tr><td><strong>Users</strong></td><td>Who holds the tenant admin and tenant viewer roles.</td></tr></tbody></table>

{% hint style="info" %}
Tenant administrators can also prevent tenant members from creating organizations of their own.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.akenza.io/general/tenants.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.