Tenants

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

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

• Workspace

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.

Deployment

Tenant roles

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

Role	Access
Tenant admin	Read-only across all organizations, and may add themselves to any organization in order to work in it.
Tenant viewer	Read-only across all organizations.

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.

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

Deleting a tenant integration removes it from every organization and workspace that was using it. Check what depends on it before removing one.

Device type libraries

Device type libraries 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 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 for the deployment itself, the result carries your name from the address bar through to the mail that lands in someone's inbox.

This is the deployment-wide layer of branding. An individual organization on the tenant can additionally brand itself with white labeling, which is the right level when one reseller serves customers who each want their own look.

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.

Users

What is managed at tenant level

Area	What it covers
Organizations	Every organization on the tenant.
Workspaces	Every workspace, across all of those organizations.
Devices	Every device on the tenant.
General settings	Tenant integrations, device type libraries, white labeling, and single sign-on.
Users	Who holds the tenant admin and tenant viewer roles.

Tenant administrators can also prevent tenant members from creating organizations of their own.