When you invite someone to the organization, their role is set to Admin unless you change it. Admins have Owner access to every workspace in the organization. If someone only needs some workspaces, choose Member and add them to those workspaces.
Roles and access
What a person can do in Workspaces depends on two settings:
- Their organization role controls the organization: its members, its workspaces and its single sign-on.
- Their workspace access controls what they can do in one workspace. It's set separately in each workspace they're a member of.
A person can have access to a workspace without being a member of its organization. That's how you give people from outside your organization, such as contractors, access to one workspace and nothing else.
Organization roles
| What it allows | Owner | Admin | Member |
|---|---|---|---|
| See the organization and its member list | |||
| Invite and remove members and admins, and change their roles | |||
| Make someone an owner, or change or remove an owner | |||
| Create workspaces | |||
| Owner access to every workspace in the organization | |||
| Set up single sign-on | |||
| Rename the organization |
- Owner has full control of the organization. An organization always has at least one owner.
- Admin can do almost everything an owner can. Only owners can make someone an owner, change or remove an owner, set up single sign-on and rename the organization.
- Member can see the organization and its member list, and has no other rights in the organization. Members only have access to the workspaces they've been added to, at the access level they were given there, which can be anything up to Owner.
Admin is the default role
Workspace access levels
| What it allows | Owner | Full access | Limited access |
|---|---|---|---|
| See the workspace and its member list | |||
| Create new resources | |||
| Work with the workspace's other resources | With custom access | ||
| See billing and usage | With custom access | ||
| See audit logs | |||
| Add and remove members, and change their access | |||
| Make someone an owner, or change or remove an owner | |||
| Change the workspace's name and email | |||
| Delete the workspace |
- Owner has full control of the workspace.
- Full access is for people who run the workspace day to day. They manage members, resources, billing and audit logs, but can't delete the workspace or change owners.
- Limited access is for people who need only part of the workspace, such as contractors, or developers who work on one project. They can create new resources, and work only with the resources, billing and emails you grant them through custom access.
API tokens created by Owners and Full access members belong to the workspace, not to the person who created them. See API tokens in Workspaces.
Inherited access
Organization owners and admins have Owner access to every workspace in the organization, including workspaces they haven't been added to. A workspace's member list shows them as Owner, marked Inherited. Inherited access can't be changed or removed in the workspace.
If an owner or admin is also added to a workspace as a member, the access level they were given there applies instead, and the member list shows that level. For example, an admin with Limited access in a workspace works with Limited access there. Because their role still lets them manage the workspace's members, they can raise their own access at any time, so a workspace access level doesn't restrict an owner or admin.
To restrict what someone can do, change their organization role to Member, then set their access in each workspace they need. Changing the role doesn't change the access they already have as a member of a workspace, including access they gave themselves, so check each workspace too.
Custom access
Custom access gives a Limited access member access to specific things, without raising their access level. You can grant:
- Billing access and billing emails: the workspace's Billing tab and billing log, and the billing emails. The Billing details on the Overview tab stay hidden.
- Technical emails: notifications about resource deletions, the Fair Transfer Policy and incidents.
- Resources: all or selected resources of a type. The types are servers, storages, Managed Databases, Object Storage, load balancers, private networks, routers, gateways and Kubernetes clusters.
Things to know about custom access:
- Access to a server lets the member see the storage devices attached to it. To let them work with a storage device itself, for example to back it up, grant the storage device too.
- Custom access applies to the member's existing API tokens as well, so they don't need a new token after you change it.
- If you change a member to Full access and later back to Limited access, their custom access is cleared. Grant it again.
- You can set custom access once the person has accepted their invitation.
For the steps, see Set custom access.
Choose the right access
| Who | Organization role | Workspace access |
|---|---|---|
| Someone who runs the organization with you | Admin | Owner in every workspace, inherited from their role |
| A colleague who works in some of your workspaces, such as a web developer who works only in Web Shop | Member | Full access in each of those workspaces |
| A contractor who works on specific servers, such as the database servers in Data Platform | None | Limited access, with custom access to those servers and their storage devices |
| Someone who handles billing only | None or Member | Limited access, with Billing access and billing emails |
| A script, CI pipeline or other integration | None | Limited access for a separate member: see Give a script limited access |
None means that you add the person straight to the workspace, without inviting them to the organization.
When someone leaves
To remove all of someone's access:
- Remove them from the organization, if they're a member of it. They lose the Owner access they had to every workspace as an owner or admin.
- Remove them from each workspace they were added to directly. Removing someone from the organization doesn't remove them from these, and they keep the access level they had there.
- If they had Owner or Full access in a workspace, delete the API tokens they created there. Those tokens belong to the workspace and keep working after the person has gone.
Resources the person created stay in the workspace.