Organization Management

Overview

An Organization (Org) is a resource and access boundary within a WEDA Tenant. Most operational resources — such as devices, container stacks, registry credentials, and AI models — are scoped to an Org. Users are different: a user can be assigned to multiple Orgs, with a role in each Org.

Each Tenant is an independent boundary and Tenants do not form a hierarchy. Within a Tenant, WEDA uses a hierarchical organization tree: a Root Organization sits at the top, and Sub Organizations can be nested beneath it. This structure can represent teams, sites, factories, or production lines. Most deployments start with a Root Org and add Sub Orgs when more detailed resource separation is needed.

Tenant and Organization are different boundaries

A Tenant is an independent top-level boundary managed through WISE Portal. An Organization is created within a Tenant and managed through WEDA Core. An Org hierarchy never crosses Tenant boundaries.

This documentation describes SaaS behavior

WEDA is available as a SaaS deployment or an on-premises deployment. This documentation describes SaaS behavior, which is the standard going forward. On-premises deployments currently differ in hierarchy visibility (see below) — contact WEDA support if you need on-prem-specific guidance.

Resource Isolation

Org-scoped operations commonly include an orgId path parameter. Other APIs derive their scope from the authenticated Tenant, the user's Org memberships, or the target resource. The platform enforces these boundaries server-side — changing an orgId in a request does not grant access to that Org.

The following resources are org-scoped:

Resource	Org Scope
Devices	Linked to one Org; accessible only to users authorized for that Org
Container Stacks	Defined per org; deployments target devices in the same org
Registry Credentials	Defined per org; available to stacks within the same org
AI Models	Managed per Org; deployment operations target authorized devices
Data	Data objects and telemetry are scoped to the device's org
Users	Can be assigned to multiple Orgs; the user's role applies within each assigned Org

Client Credentials and Reports are Tenant-scoped rather than Org-scoped.

Visibility and resource access are both determined by the user's own Org memberships — there is no automatic inheritance based on the hierarchy, in either direction. A user assigned only to the Root Org cannot access Sub Org A's devices, stacks, models, or data — and in a SaaS deployment, cannot even see that Sub Org A exists — unless they are separately assigned to Sub Org A.

Parent membership grants neither visibility nor access

Being an admin in a parent Org does not automatically grant visibility into its child Orgs, nor access to their resources. The user must be assigned to each Org they need to see or manage.

The hierarchy does affect one thing: eligibility to be added to an Org. A user must already be an admin in a parent Org before they can be added to one of its child Orgs (see User & Role Management — Constraints). This is a membership prerequisite, not a visibility grant — being an admin in the parent does not automatically add the user to, or grant visibility into, the child.

Each box represents the set of resources visible only to users individually assigned to that org. The dotted lines show the parent-child hierarchy structure — this structure gates who is eligible to join a child org, but does not by itself grant cross-box visibility.

Operations

Basic CRUD

Operation	API	Description
Create Organization	POST /api/v1/orgs	Create a root or sub-organization. Set parentOrgId to place it under an existing org.
List Organizations	GET /api/v1/orgs	List accessible Orgs as paged results, a flat list (view=list), or a hierarchy (view=tree).
Get Organization	GET /api/v1/orgs/{orgId}	Retrieve details of a specific org.
Update Organization	PATCH /api/v1/orgs/{orgId}	Modify name or description.
Delete Organization	DELETE /api/v1/orgs/{orgId}	Remove an org. Requires orgName confirmation in the query parameter.

Hierarchy Traversal

Operation	API	Description
Get Child Orgs	GET /api/v1/orgs/{orgId}/children?depth=n	Retrieve the subtree beneath an org, up to n levels deep.
Get Parent Orgs	GET /api/v1/orgs/{orgId}/parents?depth=n	Traverse upward in the hierarchy, up to n levels.

If depth is omitted, the default value is 1.

note

These endpoints only return Orgs the caller is authorized to access. A parent Org admin who has not been separately assigned to a child Org will not see that child Org in the results, even though it exists in the hierarchy.

Constraints

Create

• name is required, max 100 characters
• name must be unique within the Tenant
• description is optional, max 200 characters
• admins is optional and can assign existing users as Org admins during creation
• parentOrgId is immutable after creation — an org cannot be moved to a different parent

Current Org role

In the current release, admin is the only supported Org role. Other role values are not yet implemented.

Update

• Only name and description can be modified

Delete

• Requires orgName query parameter for confirmation
• The org must have no child organizations
• The org must have no linked devices or other users
• The Root Organization cannot be deleted

Scenario

A system integrator deploys WEDA for two manufacturing clients. They set up the following org structure:

1. Create Root Org — represents the integrator's top-level operational organization within the Tenant
2. Create Sub Org A (parentOrgId = Root) — client: Factory Tainan
3. Create Sub Org B (parentOrgId = Root) — client: Factory Taichung

When the Tainan factory's on-site engineer logs in, WEDA returns only the devices, stacks, and data linked to Sub Org A. The Taichung factory's resources remain invisible — enforced by orgId scoping at the API level, with no additional configuration required.

Because the integrator assigned themselves as admin to each Sub Org during creation, they can query the Root Org using GET /api/v1/orgs/{rootOrgId}/children?depth=2 to retrieve two levels of the Org tree in a single call. Had they not been individually assigned to Sub Org A and B, those Orgs would not appear in the response — hierarchy traversal follows the same membership rule as resource access.

Related

To assign users to an organization or manage their roles, see User & Role Management.

• Postman walkthrough: Manage Organizations

---

Last updated on Jul-17, 2026 | Version 1.1.0