User & Role Management

Give a colleague access to the organizations they need to manage. Start by confirming that their user account exists in your Tenant, then assign their membership in each required organization.

Tenant membership and Org membership answer different questions: does this user belong to the Tenant, and which Org can this user manage? A Tenant user must exist before you can assign them to an Org.

Level	Where you manage it	What the assignment means
Tenant	WISE Portal	The user belongs to the Tenant as a Tenant Admin or Tenant User.
Organization	WEDA Console or organization-user APIs	The user has a role in a specific Org and access to that Org's resources.

Tenant-Level Users (WISE Portal)

Use WISE Portal when a person is joining your Tenant for the first time. Adding an Org membership in WEDA Core uses an existing user account.

1. Ask your Tenant administrator to confirm whether the user already belongs to the intended Tenant.
2. If the user is new to the Tenant, have an authorized administrator invite or add them through WISE Portal.
3. Confirm that the user exists in the Tenant before assigning any Org memberships.

Check the result: The user has an existing Tenant account that you can identify for the Org assignment. For an API request, obtain their system userId; a display name or email address cannot replace the required user ID.

Note: Tenant administration and Org administration have different scopes

Use WISE Portal to manage Tenant users. Use WEDA Console or the organization-user APIs to assign access to individual Orgs. Removing an Org membership does not remove the user's Tenant account.

Organization Memberships (WEDA)

Use WEDA Console or the organization-user APIs to manage which existing Tenant users can access each Org.

Understand Org Membership and Roles

WEDA Console currently offers Admin as the only Org role. The organization-user API accepts admin when adding members. An Org admin manages that Org's users, devices, container stacks, registry credentials, AI models and data. Confirm this scope before granting access.

Membership is assigned per Org. A parent-child relationship between organizations does not automatically assign users to the child. The current API provides add and remove operations for Org membership; it does not provide an operation to change an existing member's role.

Add Users to an Organization

Before adding a member, confirm:

• Existing user: The person already belongs to the Tenant, and you have the correct userId.
• Your permission: You are an admin of the target Org when using the organization-user API.
• Assigned role: Use admin, the role accepted by the current add-users API.
• Parent membership: If the target has a parent Org, the person being added is already an admin in that parent.

Assign memberships from parent to child:

This example uses an existing hierarchy: Root Org > Factory A > Line A1. Perform each assignment separately, starting with the first required ancestor. Confirm your own admin membership in each target Org before making its request.

Note: Parent membership is a prerequisite, not an automatic assignment

A user must already be an admin in the immediate parent before they can be added to a child Org. Repeat the assignment at each level in a deeper hierarchy. Each parent assignment also grants access to that parent's resources, so review the full access scope before proceeding.

In WEDA Console:

1. Select the target organization in the top bar, then open Members. Check the selected Org and its existing members before adding anyone.

Confirm the target Org in the top bar before selecting Add.

2. Select Add. In Add Member, use Search to find the existing Tenant users you want to add.
3. Select the checkbox beside each intended user and confirm Admin under Org role.

Dolly Cheng is selected with the Admin role. Submit (1) indicates one selected member.

4. Select Submit, then Add in the Add Member(s) confirmation dialog.

Select Add to confirm the selected memberships.

5. Return to Members and confirm that each added user appears with the intended Org role.

The resulting list includes Dolly Cheng with the Admin role.

Check the result: The selected users are listed in the intended Org with Admin access.

Using the API:

The examples use https://weda.example.com/central/weda as the WEDA base URL. Replace the origin and tenant path with your environment, and send your user access token.

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

[
  {
    "userId": "00000000-0000-0000-0000-000000000001",
    "orgRole": "admin"
  }
]

Replace the example UUID with the existing Tenant user's actual userId. The request body is an array, even when adding one person. You can include more entries to add several users to the same Org.

Check the result: The API returns 201 Created, with the created memberships in request order. Query the target Org's users to confirm the assignment.

If the request fails: All entries are validated before any membership is added. If one entry fails, the entire batch is rejected.

Response	What to check
400 Bad Request	The array is non-empty, each userId is a valid GUID, and every orgRole is admin.
403 Forbidden	You are an admin in the target Org, and each user being added is already an admin in its parent, if it has one.
404 Not Found	The target Org, parent Org and all users exist.
409 Conflict	A user is already a member of the target Org. Check existing memberships before retrying.

See Add Users to an Organization for the complete contract.

View Users and Memberships

Choose the lookup according to what you need to confirm:

• Who belongs to this Org? Check the Org's member list.
• Which existing user account is this? Look up the application user's profile and system ID.
• Which Orgs is this person assigned to? Query the user's Org memberships and roles.

In WEDA Console: Select the intended organization, then open Members. Confirm the selected Org before interpreting its member list. A missing member should be checked against the assignment in that specific Org.

Using the API: Prefix these paths with your WEDA base URL and send your user access token. Results depend on the caller's permissions.

What you need	Request and API reference
Members of one Org	List Users in an Organization: GET /api/v1/orgs/{orgId}/users
One user's membership in that Org	Get a User in an Organization: GET /api/v1/orgs/{orgId}/users/{userId}
Existing application users you are allowed to list	List Users: GET /api/v1/users
A user's profile	Get User: GET /api/v1/users/{userId}
A user's Org memberships and roles	List a User's Organizations and Roles: GET /api/v1/users/{userId}/orgs

For the Org member list, use skipCount and maxResultCount for pagination, name for a partial-name match, and sorting to order by name, orgRole or userId. For the application-user list, filter supports a fuzzy search, and sorting supports name or email.

The user-membership lookup supports orgId or a partial orgName filter. It returns a tree structure; sorting does not apply to that endpoint. These lookup operations read existing records; inviting a new Tenant user still happens through WISE Portal.

Check the result: Match the person's system userId, the target orgId and the assigned role. A profile lookup alone does not prove membership in a particular Org.

Remove Users from an Organization

Remove the membership when a person no longer needs that Org's access. Review the affected hierarchy before making the request.

Before: Root + Factory A + Line A1 + Factory B
Action: Remove membership in Factory A
After:  Root + Factory B
        Factory A and descendant Line A1 memberships are removed

The user remains in the Tenant, and memberships in unrelated Org branches remain unchanged.

Caution: Removing a parent membership also removes descendant memberships

Removing a user from an Org also removes their membership from all sub-organizations beneath it. Check whether they still need any descendant access before proceeding. Choose the specific child Org when only that child's membership should be removed.

Before removing a member, confirm:

• You are an admin in the target Org.
• You are removing another user's membership. An admin cannot remove their own membership.
• Another admin will remain in the target Org. Its last admin cannot be removed.
• You have reviewed the user's memberships beneath the target Org.

In WEDA Console:

1. Select the intended organization in the top bar and open Members. Verify the person and Org before proceeding.
2. Select the target member's trash icon under Actions.
3. In Delete Members, check the member's name and the organization. The confirmation includes removal from that Org and all its sub-organizations.

The confirmation includes TestOrg and its sub-organizations. Review that scope before selecting Delete.

4. Select Delete to confirm removal.
5. Return to Members and verify that the target user is no longer listed and the remaining admin is still present.

The removed member no longer appears in the list.

Check the result: The target membership is removed from the intended Org. The person's Tenant account remains separate from this Org membership.

Using the API:

1. Confirm the target user's memberships using the Org-user and user-membership lookups above.
2. Check the target Org's member list to identify the admin who will remain.
3. Send the removal request for the intended Org and user.

DELETE https://weda.example.com/central/weda/api/v1/orgs/{orgId}/users/{userId}
Authorization: Bearer {accessToken}

Check the result: The API returns 204 No Content. Query the affected memberships again to confirm that the target and descendant assignments are gone and any unrelated assignments remain.

Response	What to check
403 Forbidden	You are an admin of the target Org and are not attempting to remove yourself.
404 Not Found	The specified Org and user exist.
409 Conflict	The request would remove the Org's last admin. Assign another admin before retrying.

See Remove a User from an Organization for the complete contract.