Invite and manage users
Getting people onto the platform. Users are invited per workspace, not per organization, so the same person can belong to several workspaces with different admin rights in each.
You need to be a Workspace Admin or Organization Admin to invite anyone.
Identity vs user
Rescale separates two things that most platforms treat as one, and the distinction explains most of the behavior that surprises administrators. An identity is a single email address with access to Rescale, and it can belong to many workspaces. A user is that identity's membership of one workspace, so one identity can be several users.
Removing someone from a workspace therefore removes a user and not necessarily their identity. If they belong to another workspace they still have platform access, which is why "I removed them" and "they can no longer sign in" are different statements. It is also why re-inviting a previously removed person behaves differently depending on whether their identity survived: see offboarding.
Invite users
- Hover your email at the bottom of the sidebar, choose Admin, and open the Workspace Admin portal for the workspace.
- Go to Teams > Invite Members.
- Enter email addresses and names, one member per line, with the name and email separated by a comma or tab.
- Optionally pick a group, so invitees join it automatically when they accept.
- Click Send Invitations.
Each invitee gets a verification email. They can sign in once they've verified.
Don't share a login across a team. Beyond the security problem, per-user logins are what make audit logs, member budgets, and license attribution meaningful. A shared account makes all three useless.
If you use SSO
With SSO configured, whether an invitation is needed depends on your access policy:
See SSO.
Default workspaces
A user's default workspace (the one they land in at sign-in) starts as whichever workspace first invited that email address.
Users can change it themselves under Preferences > Default Workspace. If someone complains about landing in the wrong place every morning, point them there rather than at support.
Admins can't set it on a user's behalf from the portal.
Switch between workspaces
A user belonging to several workspaces picks their active one from the workspace name at the top of the sidebar. The switcher lists each workspace with its ID.
The workspace ID matters for cross-workspace sharing. You need the recipient's ID as well as their email.
What the Members list shows
Workspace Admin > Teams > Members lists everyone in the workspace with:
Filter by All, Active, Pending or Invited to narrow the list. The Invited filter is the one worth knowing, because it finds people who were invited but never verified their account, and that is a common cause of someone reporting that they have no access when the admin can see them in the list.
This is a different control from the workspace-wide running core limits, which cap cores across everyone at once. Max Concurrent Jobs caps one person's job count, which is what you want when a single parameter sweep would otherwise consume the workspace's capacity and you do not want to constrain the rest of the team to prevent it.
Delegate admin rights
There are two admin roles, and only an Organization Admin can grant either of them. An Organization Admin administers the whole organization and every workspace in it. A Workspace Admin administers one workspace and cannot reach organization-level settings such as SSO, password policy or commitment plans.
You grant both from the organization's Teams > Members page, using the checkboxes against each user-and-workspace pairing. Because the grant is per pairing, someone who belongs to several workspaces gets admin rights set separately in each, and being an admin of one workspace does not make them an admin of another.
Groups and projects
Groups collect users so permissions and project membership can be assigned in bulk rather than per person. Adding a user to a group at invitation time is the cheapest moment to do it.
Group and project membership changes are recorded in audit logs.
Related
- Offboard a user — the removal path, and what's unrecoverable
- Custom usernames — making cluster activity attributable
- Single sign-on — authentication for invited users
- Organizations & workspaces — the structure users belong to
- Audit logs — what's recorded about user changes