Skip to main content

Organization Management

Use organizations to separate the devices and application resources managed by different teams or sites. This guide explains how that structure relates to access, then covers creating, viewing, updating and deleting organizations through WEDA Console and APIs.

Organizations and Access Boundaries​

The lines describe the parent-child organization structure within one Tenant. This structure can represent an integrator, its customer factories and their production lines. Each organization in the tree has its own resource and access scope, including Line 1 and Line 2.

Distinguish Tenant, Organization and Membership​

ConceptWhat it means for you
TenantAn independent top-level boundary managed through WISE Portal. Tenants do not form an organization hierarchy, and an Org tree stays within one Tenant.
OrganizationA boundary for the devices, application resources and device data managed by a team or site. Root and Sub Orgs both define resource scopes.
Membership and roleYour assignment to a particular Org and your role there determine your access to that Org's resources. A user can have memberships in several Orgs.

For example, creating Factory Tainan beneath the integrator's Root Org records where the factory sits in the hierarchy. The integrator's user account must also be assigned to Factory Tainan to access its resources.

Identify Which Resources Belong to Each Organization​

ResourceOrganization scope
DevicesA device is linked to one Org and accessed through that Org's authorization scope.
Container stacksStack definitions belong to an Org; deployments target devices in the same Org.
Registry credentialsRegistry configurations belong to an Org and are used by stacks in that Org.
AI modelsModels are managed within an Org, with deployment operations targeting authorized devices.
Device dataDataStreams and telemetry follow the device's Org scope.
User membershipsA user can be assigned to multiple Orgs. Each assignment applies within its own Org.

Many organization-scoped API requests identify the target with orgId; others derive the scope from the target resource or authenticated context. The request still needs authorization for that scope. Changing an orgId in a request does not grant access to the target organization.

Read Resource Access Separately from the Hierarchy​

Each frame is one Org's resource boundary. The arrows show this example user's access through explicit memberships in Root and A. Factory Taichung remains outside those assigned scopes. Line 1 and Line 2 also need their own assignments, even though the hierarchy places them beneath A.

For the same user, compare these membership combinations:

User is assigned to...Root resourcesA resourcesA1 resourcesB resources
Root onlyYesNoNoNo
Root and AYesYesNoNo
Root, A and A1YesYesYesNo
Root, A and BYesYesNoYes

These examples use Org admin memberships. They show the access boundaries; adding memberships is covered in User & Role Management.

Note: Parent membership does not grant child visibility or access

Being an admin in a parent Org does not automatically add you to a child Org or give you access to its devices, stacks, models or data. In SaaS, a child Org also remains outside your visible organization results until you are assigned to it. Confirm membership in each Org you need to see or manage.

Note: Joining a child Org has a parent prerequisite

The organization-user API requires a user to be an admin in the parent Org before that user can be added to a child Org. The child assignment is still a separate operation. Satisfying the parent prerequisite does not automatically create it. The current API accepts the admin Org role.

The visibility behavior above describes SaaS. On-premises deployments can differ in hierarchy visibility; contact your WEDA support team for deployment-specific guidance. Keep hierarchy, visibility and resource access as separate checks when investigating an organization you cannot see or manage.

Create an Organization​

Before creating an organization, sign in with a user account authorized to create it. For a sub-organization, identify its intended parent and confirm that you can create organizations beneath it.

The Console example creates TestOrg2 beneath TestOrg.

In WEDA Console:

  1. Open Organizations and select Add.
  2. Complete Basic information:
    • Parent organization: Select the parent for a sub-organization. Leave it unset when creating a root organization.
    • Organization name: Enter the name, up to 100 characters.
    • Description: Optionally describe its purpose, up to 200 characters.
  3. In Org admins, assign at least one administrator.
Add organization form with TestOrg as the parent, TestOrg2 as the name, an empty Description and an assigned Org admin.
Create TestOrg2 under TestOrg and assign its Org admins before submitting.
  1. Select Submit, then Add in the confirmation dialog.
Add Organization confirmation dialog with Cancel and Add buttons.
Select Add to confirm creation.
  1. Confirm that the organization appears in the list. Check the selected organization in the top bar and switch to the new organization when you want to manage its resources.

Check the result: The new organization is listed, and you can identify the organization in which you will manage resources.

Using the API:

Send a user access token with the request. The examples below use the WEDA base https://weda.example.com/central/weda; replace the origin and tenant with your environment.

POST https://weda.example.com/central/weda/api/v1/orgs
Authorization: Bearer {accessToken}
Content-Type: application/json

{
"name": "TestOrg",
"description": "Organization for the first edge deployment",
"admins": [{"userId": "your-existing-user-id"}]
}

For a sub-organization, also include parentOrgId with the existing parent's ID. The API requires name; description, parentOrgId and admins are optional request fields. The Console form asks you to assign administrators.

Check the result: The API returns 201 Created. Save the returned orgId for subsequent organization-scoped requests. If the name is already in use, the API returns 409 Conflict; choose another name. In Postman, verify that your org_id environment variable identifies the intended organization before using later requests.

See Create an Organization for the full request and response.

Note: Choose the parent when creating the organization

The update operation changes the organization's name and description. It does not change its parent. Choose the intended hierarchy before creating the organization.

View Organizations and Hierarchy​

In WEDA Console:

  1. Open Organizations and search for the organization you need.
  2. Expand the arrow beside a parent to view its child organizations. Check the name, description, administrator information and My org role.
Organizations list showing TestOrg marked Current, TestOrg2 beneath it, and Admin roles for both organizations.
TestOrg2 is listed beneath TestOrg. The Current marker identifies the selected organization.
  1. Open the organization menu in the top bar and select Browse all orgs.
Top-bar TestOrg menu showing the current organization and Browse all orgs.
Browse all orgs opens the organization selector.
  1. In Switch Organization, expand the parent when needed and select the organization you want to use.
Switch Organization dialog with a search field, TestOrg marked Current and its child TestOrg2.
Select TestOrg2 to change the active organization to the child.
  1. Confirm that the top bar shows the intended organization before managing its devices or other resources.
WEDA Console top bar showing TestOrg2 as the selected organization.
The top bar now shows TestOrg2.

Check the result: You have selected the intended organization and confirmed your access. If an organization is missing, check your membership with its administrator.

Using the API:

What you needRequest
Paged organizationsGET /api/v1/orgs?view=page
A flat listGET /api/v1/orgs?view=list
A hierarchy viewGET /api/v1/orgs?view=tree
Organizations under a parentGET /api/v1/orgs?parentOrgId={parentOrgId}
One organization's detailsGET /api/v1/orgs/{orgId}
Child organizations up to two levels below itGET /api/v1/orgs/{orgId}/children?depth=2
Parent organizations up to two levels above itGET /api/v1/orgs/{orgId}/parents?depth=2

Prefix these paths with your WEDA base URL and send your user access token. The list endpoint defaults to paged results; without parentOrgId, it retrieves root-level organizations. Use skipCount, maxResultCount and sorting for paging and sorting. The parent and child traversal endpoints default to depth=1 when omitted.

Read the response shape for the selected view: page returns items and totalCount; list returns items without totalCount; tree returns an array of root nodes with nested children.

The parents endpoint returns one path from the highest ancestor reached within depth down to the requested organization, which is the last node. Each node's children contains only the next node on that path. With depth=1, the highest node is the direct parent, not necessarily the root organization.

Hierarchy queries follow the caller's access boundaries. Use membership checks when investigating an incomplete view of the hierarchy.

See List Organizations, Get Organization, List Child Organizations and List Parent Organizations.

Update an Organization​

Update the name or description when the organization's purpose or naming changes. Keep the existing orgId as the identifier for the update.

In WEDA Console:

  1. Open Organizations, find the target organization and select its pencil icon under Actions.
  2. In Edit organization, change Organization name or Description. Parent organization is read-only.
Edit organization form for TestOrg2, with TestOrg as a disabled parent field, editable name and description, and Submit buttons.
Edit the organization's name or description. Its parent cannot be changed here.
  1. Select Submit and complete any confirmation presented by the Console.
  2. Return to the organization list and verify the saved name and description.

Using the API:

PATCH https://weda.example.com/central/weda/api/v1/orgs/{orgId}
Authorization: Bearer {accessToken}
Content-Type: application/json

{
"name": "TestOrg",
"description": "Updated organization description"
}
  1. Identify the target organization and confirm that your account is an admin in it.
  2. Include name, up to 100 characters, even when changing only the description. Use the current name when keeping it unchanged.
  3. Include the description you want to save, up to 200 characters.
  4. Send the update and read the organization again to check the saved values.

Check the result: The update returns 200 OK, and the organization's details show the intended name and description. If the request is rejected, check the reported name conflict, field limits and your access before retrying.

See Update an Organization.

Delete an Organization​

Before deleting, confirm the target organization's ID and current name. The API permits deletion only when:

  • Your account is an admin of the target organization.
  • The target is not a root organization.
  • It has no child organizations, linked devices or other users.
Caution: Check the organization before deleting

Confirm that the organization you intend to remove matches both orgId and orgName. Inspect its child organizations, devices and memberships before changing them to satisfy the deletion requirements.

In WEDA Console:

The delete action is disabled for the Current organization. Use the top-bar organization selector to switch to a different organization before deleting the target. The deletion requirements above still apply.

  1. Open Organizations, find the intended child organization and select its trash icon under Actions.
  2. In Delete Sub-organization, check the displayed organization name and deletion eligibility message.
Delete Sub-organization dialog for TestOrg2, showing a no-devices eligibility message, a field to re-enter the organization name, and a disabled Delete button while the field is empty.
Check the target and eligibility message, then re-enter the organization name before confirming deletion.
  1. Re-enter the target organization's name in the confirmation field, then select Delete to confirm permanent deletion.
  2. Refresh the organization list and verify that the target is no longer listed.

Using the API:

DELETE https://weda.example.com/central/weda/api/v1/orgs/{orgId}?orgName={orgName}
Authorization: Bearer {accessToken}
  1. Read the target organization's current details.
  2. Check the conditions above.
  3. Send its current name in the required orgName confirmation query parameter. URL-encode the value when constructing the request URL.
  4. Confirm the result and refresh the organization list.

Check the result: The API returns 204 No Content, and the deleted organization is absent from subsequent list results. A name mismatch returns 400 Bad Request. Missing admin access, a root organization, child organizations, devices or other users can cause 403 Forbidden.

See Delete an Organization.