User & Role Management
Overview
WEDA manages user access across two separate tiers. Understanding this separation is essential before making any user management API calls.
| Tier | Managed by | Roles | Purpose |
|---|---|---|---|
| Tenant | WISE Portal | Tenant Admin, Tenant User | Establishes the user's identity and membership in an independent Tenant |
| Org | WEDA Core | admin | Controls access to resources scoped to a specific Org |
A user must exist at the Tenant level in WISE Portal before they can be assigned to any Org via the WEDA Core.
Tenant-level Management (WISE Portal)
Tenant-level user management is handled in WISE Portal, not through WEDA Core.
- Tenant Admin — full control over the entire WEDA deployment: create/delete Orgs, invite or remove Tenant Users, move devices across Orgs.
- Tenant User — a user who exists in the Tenant and can be assigned to specific Orgs by a Tenant Admin or Org Admin.
If you purchased a full on-premises deployment, you manage your own Tenant in WISE Portal. If you are on SaaS, Advantech provisions your Tenant and you can add your own Tenant Admins and Tenant Users from WISE Portal.
WEDA Core only manages Org-level assignments. To invite a new user to the system for the first time, use WISE Portal.
Org-level User Management (WEDA Core)
Once a user exists in the Tenant, a Tenant Admin or an admin of the target Org can assign that user to the Org and grant them an Org role.
Operations
| Operation | API | Description |
|---|---|---|
| Add Users to Org | POST /api/v1/orgs/{orgId}/users | Add one or more existing Tenant Users to an Org. All items validated atomically — if any fails, none are inserted. |
| List Org Users | GET /api/v1/orgs/{orgId}/users | Paginated list of users in a specific Org. |
| Get Org User | GET /api/v1/orgs/{orgId}/users/{userId} | Get a user's details within an Org context. |
| Update Org User | PATCH /api/v1/orgs/{orgId}/users/{userId} | Update the user's role in an Org. |
| Remove User from Org | DELETE /api/v1/orgs/{orgId}/users/{userId} | Remove a user from an Org and all of its Sub Orgs. Does not delete the user from the Tenant. |
| List Users | GET /api/v1/users | Paginated list of application users visible to the current caller within the Tenant authorization boundary. |
| Get User | GET /api/v1/users/{userId} | Get a user's profile when the caller has permission to view that user. |
| Get User's Orgs & Roles | GET /api/v1/users/{userId}/orgs | List the user's visible Org memberships and role in each Org. |
Org Roles
| Role | Capabilities |
|---|---|
| admin | Manage users, devices, container stacks, registry credentials, AI models, and Org-scoped data |
Currently, admin is the only accepted Org role.
The API schema may also display super_admin, operator_, and viewer. These values are reserved for future RBAC support and are not supported end-to-end in the current release. Use only admin.
Constraints
Adding users to an Org
userIdmust refer to a user who already exists in the Tenant (created via WISE Portal)orgRolemust beadmin(the only accepted value in v1.1)- If the target Org has a parent, the user must already be an admin in the parent Org before they can be added to the child Org
- For deeper hierarchies, repeat the assignment at each level; a user cannot skip a parent and be added directly to a descendant Org
- If any user in a batch request fails validation, the entire batch is rejected (atomic)
Updating roles
- Only
adminis supported end-to-end in the current release - The last admin in an Org cannot be changed to a non-admin role
Removing
- An admin cannot remove their own Org membership
- The last admin in an Org cannot be removed
- Removing a user from an Org also removes their membership from all Sub Orgs beneath it
- The user still exists in the Tenant, and memberships in unrelated Org branches are not affected
Before removing a user from an Org, verify whether they still need access to any of its Sub Orgs. All descendant memberships are removed in the same operation.
Scenario
A system integrator assigns a factory engineer to an existing Org hierarchy within a Tenant:
Once the engineer is added to Sub Org A, they can independently manage that Org's devices, stacks, models, data, and users without needing SI involvement.
Related
- Org structure and resource isolation: Organization Management
- M2M access for automated systems: Authentication — M2M Token
- API-level access control: see individual API pages for
403behavior whenorgIdis inaccessible