Roles and Permissions

Every person in CloudThinker has one organization role, and that role decides which workspaces they can open and what they can do there. Use this page to give each person the smallest role that covers their job. Every row matches a permission check CloudThinker enforces.

​

How organization and workspace roles combine

An organization is your company account: billing, members and identity settings. A workspace is a separate area inside it with its own connections, agents, findings and conversations. See Concepts for the full model. The organization Owner is the highest role and pays for the organization. Organization Admins can set up everything in the organization except the Owner-only rows in Organization permissions below.

• Override: a different role for one person in one workspace. It can raise or lower their role, for example making a Developer the Admin of their team’s workspace, or a Viewer in a workspace they should only read. Owners and Admins can’t be overridden. Set it in workspace members.
• Member is a legacy organization role. It works exactly like Developer.
• Workspace owner: not a role. It’s the single person recorded as owning one workspace. They can open that workspace in their own right, whatever their role, and they receive its notices — a connection that breaks, an alert with no other recipient. A workspace created by an organization rather than a person can have no owner at all. Where this guide says Admin, it means the role and its permissions; where it says owner, it means this one person.
• Owner: each organization has exactly one. You can’t invite someone as Owner or pick the role for them. There’s no transfer control in the app: the current Owner emails support to transfer ownership, and the old Owner becomes an Admin.

​

Organization permissions

Organization settings live in Admin Settings, which only Owners and Admins can open. A workspace Admin who isn’t an organization Admin (for example, a Developer with an Admin override) doesn’t see Admin Settings in their menu. They can open one page there from a direct link, Guardrails, and nothing else. They set their workspace’s own LLM key in More → Workspace settings → BYOK instead. Admins can invite someone as Admin but can’t promote an existing member to Admin. Nobody can be invited as Owner.

​

Workspace permissions

These apply inside one workspace. Organization Owners and Admins always get the Admin column. Deleting a workspace isn’t a workspace permission: only organization Owners and Admins can do it, from Admin Settings → Workspaces. Viewers are read-only: they can’t chat with CloudThinker, run commands, or start any agent work. The one exception is that any member, Viewers included, can install a Skills Hub skill into the workspace. Who can approve an agent’s action is set separately from these roles. See Approvers.

​

Choose a role

Every role uses a seat on per-seat plans, Viewer included, and so does each pending invitation until it expires after 7 days. Inactive members (provisioned while no seat was free) don’t use one until you activate them. See Add or remove seats. If you provision people with SCIM, new members get the Auto-assigned organization role you set there, Viewer by default.

​

What changes when a role changes

• The new role applies from the person’s next request. They don’t need to sign out.
• If someone loses access to a workspace (for example, an Admin demoted to Developer who was never added to it), the automations they own there are turned off. A workspace Admin can take ownership and turn them back on.
• Removing someone from the organization removes them from every workspace. Members provisioned through SCIM are removed in your identity provider instead.
• Role changes, invites and removals are recorded in audit logs.

​

Next steps