Skip to main content
An organization is the unit everything else hangs from. Your telemetry, license keys, dashboards, alert rules, SLOs, synthetic checks, users and plan all belong to exactly one. There is no “project” or “workspace” layer beneath it. If you want two environments separated so that neither can see the other, that is two organizations. If you want them separated so that they are easy to tell apart, that is a resource attribute — see Separating environments below, which is what almost everyone actually wants.

​
How isolation works

Every telemetry row carries the organization it belongs to, attached by the receiver from your license key, and every query filters on it.
The boundary is the key, not the payload. Your organization is derived from the license key on the request. An exporter cannot claim to be a different organization by setting an attribute, because nothing downstream reads tenancy from the payload.The same rule cuts the other way: you cannot route some services to a second organization by tagging them. Use a second organization’s key.
The same applies at the API. Many endpoints accept a tenantId query parameter — a historical artefact — and it is always overwritten from your session. Naming an organization other than your own returns 403 rather than being silently corrected, so a mistake is visible instead of quietly returning your own data under someone else’s name.

​
Belonging to more than one

A user account is global; membership is per organization. One person can be an Owner of one organization and a Viewer of another, with one set of credentials. Your session is scoped to one organization at a time. Switching organizations issues a new session with the role you hold there.
A license key belongs to one organization, and does not follow you when you switch. If telemetry is arriving but you cannot see it, confirm that the organization the key was created in is the one you are looking at. This is the third most common cause of “my data is missing”, after the time range and a hardcoded timestamp — and it is the one that produces no error anywhere.

​
Separating environments

Most teams asking for multi-tenancy want to keep staging out of their production dashboards. Two organizations is the heavy answer: separate keys, separate users, separate alert rules, nothing shared. The light answer is a resource attribute, and it is usually the right one:
Everything in the product filters on it, dashboards can be scoped to it, and alert rules can be written against it — while you keep one set of keys and one place to look. Choose separate organizations when the requirement is access control. Choose an attribute when the requirement is tidiness. See Resource attributes.

​
What crosses an organization boundary

Nothing in the telemetry path. Two things in the control plane are worth knowing about:
  • Your user account. One identity, many memberships. Changing your password changes it everywhere, and signing out of all sessions signs you out of every organization.
  • Support access. aiAxonIQ support staff can be granted time-limited access to an organization to investigate a ticket. Every such session is recorded in your audit log with who, when and for how long, and it is visible to you — not only to us.

​
Creating another organization

Requires the Owner role. The creator becomes its Owner; members are invited separately, and membership in one grants nothing in the other.
During the private beta, organizations are created by invitation. If you need a second one — a separate production tenancy, an isolated environment for a customer of yours — ask your account contact rather than looking for a self-service button. See Create your account.

​
Next

Roles and permissions

The five roles, what each can do, and the rules on granting them.

License keys

The credential that decides which organization data lands in.

Plan limits

What is counted per organization, and what happens at the ceiling.