Roles & Access

logiccloud orchestrate is multi-tenant. What you can see and do is governed by two things:

Your role inside the current tenant (organization) — admin, operator, or viewer.
Any system role you hold across the whole platform — SUPERUSER or SUPPORT.

The server enforces every permission. The sidebar only shows the modules your role can use, so two people signed into the same tenant may see different menus. Your role badge (sidebar, header menu and profile) always shows the role the server holds for you in the current tenant.

Tenant roles

Every member of a tenant has exactly one of these roles. The web UI assigns these built-in roles. The API also supports custom roles that combine individual permissions (/api/v1/organizations/{orgId}/roles).

Role	In a nutshell
admin	Full control of the tenant — everything below, plus users, alerts, audit log, settings
operator	Day-to-day operations — manage devices, device groups, deployments and registries
viewer	Read-only — see devices, device groups, applications, deployments and certificates

What each role can do

“Edit” means create and update; “Manage” additionally means delete. A dash means the module is not shown to that role and its API refuses the role.

Area	viewer	operator	admin
Dashboard	View	View	View
Devices	View	Manage	Manage
Device Groups	View	Manage	Manage
Applications	View	Edit	Manage¹
Deployments	View	Manage + roll out	Manage + roll out
Certificates	View	View + revoke²	Manage
Repositories (Git/OCI)	—	Manage³	Manage³
API Keys	Own keys	Own keys	All keys
Users	—	—	Manage
Alerts	—	—	Manage
Audit Logs	—	—	View
Settings (tenant)	—	—	Manage
Profile (your own)	Yes	Yes	Yes

Notes:

¹ Admins delete application versions. Deleting a whole application package is for superadmins only.
² Operators revoke device certificates.
³ The settings of a linked FLECS store are for superadmins only.
Deployments: operators and admins have the same rights. They create, roll out, re-deploy and delete deployments, and approve the next batch of a rolling rollout (Approve Batch).
Devices and device groups: operators and admins edit and delete devices (one at a time or in bulk) and create, change and delete device groups. Viewers see no edit or delete action, and the API refuses them.
Certificates: operators view certificates and can revoke a device certificate. Adding, renewing and deleting CA certificates is for admins.
Repositories: Git and OCI registries have separate permissions. The operator and admin roles hold both. A custom role or API key needs the OCI registry permissions to work with OCI registries; roles and keys that already had the Git registry permissions also received the OCI ones, so their access did not change.
Buttons follow permissions: the web UI shows an action only when your role allows it. A viewer, for example, sees no Deploy, Re-deploy, Delete or Revoke button.
API keys are managed from Settings → Security. Every role can create its own keys, but a key can never hold more permissions than its creator: the server refuses a key with a permission you do not have. If your role is later reduced, your existing keys lose the permissions you no longer hold. Admins see and manage every key of the tenant; everyone else sees only their own.

System roles

System roles are granted at the platform level and apply across every tenant.

System role	What it grants
SUPERUSER	Cross-tenant administration: act in any organization, create and administer tenants, switch tenant context. Bypasses tenant role checks.
SUPPORT	Support and troubleshooting: inside a tenant switched into with a reason, the rights of a tenant admin. No platform administration.

A superadmin (SUPERUSER) sees the Tenants module and can switch into a tenant they are not a member of, with a reason. A user with the SUPPORT role follows the same rule. Without an open switch, the API rejects a request for such a tenant with 403 TENANT_SWITCH_REQUIRED, in the web UI and for direct API calls. Members of a tenant need no switch there. Tenant switches are recorded in the audit log. See Tenant scoping and tenant switching.

What only a superadmin can do

A tenant admin has full control inside the tenant. These actions are for superadmins (SUPERUSER) only:

Create, rename, enable, disable, suspend and delete tenants.
Manage platform users across tenants: create, enable, disable, delete, reset passwords, add to or remove from tenants.
Grant and revoke the SUPERUSER and SUPPORT system roles.
See and export activity across all tenants.
Link and configure the FLECS store of a tenant.
Manage corporate sign-in group mappings (Federation Mappings).
Check and repair a user’s tenant assignment (tenant consistency).
Delete a whole application package.

A SUPPORT user cannot do any of these.

Tenant switch duration

A switch ends after 8 hours by default.
In the switch dialog you can choose a custom end time instead, at most 72 hours ahead.
While a switch is open, the switch notice shows when it ends. Use Extend to move the end time (again at most 72 hours ahead) with a reason, so a long task is not cut off. The notice turns red when less than 30 minutes remain.
Every extension is recorded in the audit log with the reason and the previous and new end time.
Signing out of the web UI ends the switch. A CLI or SDK client does not sign out through the web UI, so it relies on the end time.

Everyone sees Dashboard, Devices, Device Groups, Applications, Deployments, Certificates, API Keys and their Profile.
Repositories appear for admins and operators.
Users, Alerts and Audit Logs appear for admins.
Settings is in the user menu at the top right. Everyone can open it; only admins can save tenant settings such as branding.
Tenants appears only for superadmins and for users who belong to more than one tenant.
Federation Mappings appears only for superadmins (see Corporate sign-in).

See each module guide for the exact actions available on that page.