Managing members and RBAC

OpenWork Cloud separates org membership from team assignment. Teams are used for Collection and provider access; roles control what a person can manage across the org. An explicitly approved team can also grant organization-wide Admin access to its members.

​

Roles

OpenWork Cloud has three roles:

• Owner: full org control. Only the owner can delete the organization or transfer ownership.
• Admin: can invite Member users, manage ordinary teams, remove members subject to access safeguards, manage shared Cloud resources, connections, providers and usage limits, start a subscription, and view settings such as SSO, SCIM, API keys, approved web origins and desktop policies.
• Member: can use resources shared with them but cannot manage org administration.

Super Admin no longer exists as a built-in role. Ordinary admins keep their previous capabilities. The following actions default to the owner unless granted through Permissions:

• changing member roles and inviting someone as an Admin
• designating Admin teams and changing who is in them
• organization settings, branding and approved web origins
• managing SSO, SCIM, organization API keys, desktop policies and network diagnostics
• opening the billing portal
• editing or removing a connection someone else added

​

Upgrading from before Super Admin was removed

When an upgrade first removes the old role, active people whose stored role includes super-admin become Admin and join a visible Super Admins team (with an organization-specific suffix). Its Super Admins Permissions set preserves the 14 comparable former capabilities, including managing permissions. The owner can review the team in Members › Teams, remove people, edit or unlink the permission set, or delete it through Permissions. Subsequent startups do not restore revoked access. The upgrade uses only the roles stored at that moment, not invitation or audit history. It excludes removed members, unaccepted invitations, pending workspace claims, and people already demoted. Owners keep their existing access without joining the team. Organizations without active super-admins and fresh installations get no extra team. Existing teams, including Admin teams, are unchanged. This preservation applies only if the database has not yet run the Super Admin deprecation migration. It does not repair databases that already ran it, including existing 0.18.58 and 0.18.59 installations. Those organizations need an owner-reviewed manual grant. Agent-permission and deployment management are not included: they were not comparable former super-admin capabilities. Custom roles have also been removed; members who had one are treated as Member. Enterprise organizations can use Permissions to give any of the owner-only actions to admins or to a team, and to change what members and admins can do. Owner cannot be assigned through an invitation or the role editor. Ownership can only be transferred to an active admin, and the previous owner becomes an admin.

​

Invite members

1. Open Members.
2. On the Members tab, click Add member.
3. Enter the teammate’s Email.
4. If you are the owner, choose the initial Role: Member or Admin. Admins can invite only Member users.
5. Click Send invite.

Invites are tied to the invited email address.

​

SSO just-in-time provisioning

When SSO just-in-time provisioning adds someone to an organization on first sign-in, OpenWork assigns the baseline Member role. IdP attributes such as role, groups, or admin are not used to grant OpenWork organization roles. Elevated access requires an explicit OpenWork role assignment, ownership transfer, or approved Admin team. A SAML group attribute or an identity-provider group named Admins does not grant a role on its own.

​

Restrict who can join

If you only want teammates from specific companies or domains to join:

1. Open Settings › General (the page is titled Org settings).
2. Turn on Restrict allowed email domains.
3. Add each approved domain to the Domain allowlist.
4. Click Save settings.

When this is enabled, OpenWork Cloud only lets people join with email addresses from the approved domains. Existing invites still target a specific email address, so both checks apply: the invitee must use the invited email address and that address must match the allowlist.

​

Create teams

1. Open Members › Teams.
2. Click Create Team.
3. Set Team name.
4. Choose Team members.
5. Click Create team.

You can use teams to control access to Collections and LLM providers without assigning people one by one.

​

Manage teams with SCIM Groups

Organizations using SCIM can open Settings › SCIM and enable Create teams from SCIM groups. OpenWork then creates a team for each provisioned Group and keeps its membership synchronized from the identity provider. These teams are labeled Managed by SCIM and must be changed in the identity provider; manually created teams and memberships remain independent. To connect an identity provider, follow Okta SCIM provisioning or Microsoft Entra SCIM provisioning. When SCIM deprovisions a user, OpenWork retains a disconnected member record for organization history. The global user is deleted only when they have no other active organization memberships. Reactivate the user through SCIM before they can regain SAML access.

​

Team Admin access

An Admin team grants the built-in organization Admin role, not just administration of that team. It can be a manually managed OpenWork team or a team synchronized from a SCIM Group. Creating or syncing a team does not enable this grant automatically.

​

Approve an Admin team

1. Sign in as the organization owner.
2. Open Members › Teams and review the team’s members.
3. Select Grant organisation Admin to all members of (team name) beneath the team in the list. The same checkbox is available directly below the heading on the team’s detail page, above Overview and Access.
4. The checkbox saves immediately. In Members, check Admin via (team name) to see the source of inherited access.

Only the owner can enable or clear this checkbox. Admins, including people who inherit Admin from a team, see it locked and cannot designate another Admin team or change the designation of their own team, unless an Enterprise organization gives them that permission.

​

Direct and inherited roles

• A direct role is assigned to the person in OpenWork. Team membership does not rewrite it.
• Inherited Admin is added while the person is an active organization member of an approved Admin team. Their direct role and other grants still apply.
• Teams never grant Owner. Inherited Admin gives the same access as a direct Admin role, and does not unlock owner-only actions.
• Removing someone from one Admin team, or clearing that team’s checkbox, removes only that source of Admin access. A direct Admin role or another approved Admin team still grants Admin. Changing a direct role to Member does not remove an existing team grant.

For access reviews, inspect both the person’s direct role and every team named in Admin via. OpenWork checks current team authority on subsequent requests; the person does not need a new sign-in for team access changes to apply.

​

Who manages membership

For a manually managed Admin team, only the owner can add or remove members or delete the team. This applies whether membership is edited from the team or the member list. Admins also cannot remove an organization member with Admin team access or refresh or cancel an invitation carrying that access. A member of an Admin team who wants to leave the organization asks the owner to remove them from the team first. For a team labeled Managed by SCIM, change its name and membership in the identity provider, not in OpenWork. The owner still controls the Admin checkbox in OpenWork. Approving it means trusting the identity provider’s group-membership administrators to determine who receives organization Admin through that group. SCIM changes apply only after the identity provider sends them and OpenWork processes them successfully. A removal still waiting in an Entra provisioning cycle or Okta group push has not yet revoked access in OpenWork. Check provider provisioning logs, OpenWork SCIM health, and Admin via rather than assuming an IdP edit has taken effect. SCIM user deprovisioning removes active organization access, not just one team’s grant.

​

SCIM mapping changes and reapproval

When Create teams from SCIM groups is switched off in Settings › SCIM, OpenWork clears the affected teams’ Admin grants but retains the teams and their current memberships as manually managed teams. Retaining a team does not retain its approval to grant Admin. The owner must review the retained membership and select the Admin checkbox again if manual Admin access is intended. While team sync is off, subsequent SCIM group renames, membership updates, or group deletion do not change the retained manual team’s name, membership, or reapproved Admin grant. This does not disable SCIM user deprovisioning. Saving the already-disabled mapping mode (metadata_only) again does not clear a manual reapproval. Re-enabling team sync clears the Admin grant again and replaces retained manual membership with the SCIM group’s membership. Review the synchronized membership before approving the team again. While team sync is enabled, deleting the SCIM Group or connector also clears the affected Admin grant. Any retained team needs explicit owner reapproval before it can grant Admin as a manual team. Deleting the Group removes its synchronized team memberships; do not use retained team records as proof of continuing access.

​

Practical access pattern

A simple setup that works well for most orgs:

• keep ownership with a designated, protected Owner account
• give trusted administrators direct Admin or membership in an approved Admin team
• keep most people as Member
• use Teams to decide who can see specific Collections or providers

​

Notes

• You cannot change the org owner’s role through the ordinary role editor or remove the owner; use ownership transfer when handing over control.
• Owners and admins can manage ordinary teams and member invitations. Admin team access has the stricter rules described above.
• Only the owner can change Org settings, including allowed email domains and Allowed Desktop Versions. Admins see them read only.