Managing members and RBAC

OpenWork Cloud separates org membership from team assignment. Teams decide what people get (AI providers, plugins, connectors, agent permissions, prompts); roles decide what a person can manage across the org. A team can carry a role, so everyone in it gets that role’s permissions. Everything here lives on the Members page, which has three tabs: Members, Teams and Roles.

Roles

Members › Roles lists the built-in roles and your organization’s custom roles. Open a role to see its permissions, the teams that have it, and its History.

Built-in roles

• Owner: can do everything. Only the owner can delete the organization or transfer ownership.
• Super Admin: everything the owner can do except delete the organization or transfer ownership. A super admin holds every permission, including the owner-only actions listed below, and can make, change and remove other super admins. Only the owner or a super admin can give someone this role.
• Admin: invites people, manages teams, and runs connections and models. By default this includes inviting Member users, managing ordinary teams, removing members subject to access safeguards, managing shared resources, connections, providers and usage limits, starting a subscription, and viewing settings such as SSO, SCIM, API keys, approved web origins and desktop policies.
• Member: what everyone can do. Members use the skills, plugins, connectors and models shared with them, make their own skills and plugins, and share what they made with people and teams.

Every person in the organization has at least the Member role, whatever their teams. Teams can add to it, never take away from it. The following actions default to the owner and super admins 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
• managing permissions (custom roles and what Member and Admin can do) and agent permissions

The owner can give any of these to admins by editing the Admin role, or to some people only with a custom role.

Custom roles

A custom role gives the people in a team exactly the extra permissions they need, without making them admins. For example, a Team lead role might add Invite people, Share with everyone and View usage analytics.

• A custom role starts from Member and adds only the permissions you turn on.
• You give a role to teams. Everyone in a team with the role gets it, and one role can be on several teams.
• A team has one role: Member, Admin, or one custom role. Giving a team a custom role replaces the one it had.
• People with a custom role keep Member as their own role. The custom role comes from their team, and their row in Members shows it next to the team’s name.
• Someone in several teams gets the permissions of every role they hold.

To create a custom role:

1. Open Members › Roles and click Create role.
2. Enter a Role name.
3. Under Teams, choose the teams that should have it. You can also give it to teams later.
4. Turn on the permissions the role adds. You can only turn on permissions you have yourself.
5. Click Create role.

Creating a role needs both Manage teams and Manage permissions. Manage permissions belongs to the owner and super admins by default, so they create roles unless they give that permission to others. To change or remove a role later, open it from Members › Roles, change its permissions and click Save changes, or choose Delete role. When you invite someone, you can also pick a custom role in the Role list. They join as a Member in a team that has that role.

Organizations upgraded while Super Admin was removed

Super Admin was removed for a while and has since been restored. When the upgrade that removed it ran, 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. Restoring the role does not move anyone back: people who were super admins before are still Admin, plus the Super Admins team if they joined it. The owner can make them Super Admin again from Members › Edit role, then delete the Super Admins team if it is no longer needed. 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. Owner cannot be assigned through an invitation or the role editor. Ownership can only be transferred to an active admin or super 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. Choose the Role: Member, Admin, Super Admin or a custom role. Inviting someone as an Admin needs Change member roles (owner and super admins by default), so admins usually invite Member users. Only the owner and super admins can invite someone as Super Admin.
5. Optionally choose a Team. If you picked a custom role, choose which of its teams they join.
6. 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.

Creating teams and changing who is in them needs Manage teams (admins by default). Use teams to give AI providers, plugins and connectors to a group of people instead of one person at a time. People can be in more than one team and get what each one is given. Taking someone out of a team removes what that team gave them, unless another team or grant gives it too.

Everyone

Everyone is listed first in Members › Teams. It is every member of the organization, including people in no team. You can’t add or remove people from it, and its role is always Member. What you set on Everyone is the base for every team: its agent permissions, browser rules, models, prompts and desktop suggestions apply to everyone, and a team’s own settings change or add to them for that team’s members.

Team pages

Open a team (or Everyone) to manage it. Which tabs you see depends on your permissions.

Manage teams with SCIM Groups

Organizations using SCIM can open Settings › Auth & Security › User provisioning (SCIM) (older versions: 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, open the team, and review who is on its Members tab.
3. On the Role tab, click Change role, choose Admin, then click Change to Admin.
4. In Members, check Admin via (team name) to see the source of inherited access.

To stop a team granting Admin, change its role back to Member or to a custom role the same way. Making a team an Admin team, or turning that off, needs Manage Admin teams, which only the owner has by default. Admins, including people who inherit Admin from a team, see the choice locked unless the owner 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 or Super Admin. 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 changing that team’s role away from Admin, 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 whether the team’s role is Admin 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 › Auth & Security › User provisioning (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 set the team’s role to Admin 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
• give team leads a custom role with only the extra permissions they need
• keep most people as Member
• use teams to decide who gets which providers, plugins and connectors

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.