Skip to main content

Offboard a user

how-to · Reviewed 2026-11-02 GA

Deactivating a member shuts down everything they have running and permanently deletes at least some of their data. Neither path preserves everything, and neither can be undone.

You need to be a Workspace Admin or Organization Admin.

Two categories of data, treated differently​

The whole flow turns on a distinction Rescale makes between two kinds of data, so it is worth getting straight before you open the drawer:

  • Workload files are the inputs and outputs belonging to jobs and workstations.
  • Uploaded files are everything the member uploaded outside a workload.

Uploaded files are permanently deleted on both paths. The choice you are offered only decides what happens to workload files: transfer them to another member, or delete them too. There is no option that keeps a departing member's uploaded files, so if any of them matter, download them before you start.

Before you deactivate​

Running work is shut down, and this cannot be undone

Deactivation shuts down every running job, workstation and storage device the member owns. There is no grace period and no queue, so a multi-day simulation in progress ends.

Files are saved back to the platform before each workload shuts down, so the results of work in flight are not lost in the shutdown itself. What happens to them next is decided by the path you choose.

Check what they have running first. The confirmation step reports four counts for you, their active jobs and their currently running jobs, workstations and storage devices, so you see the scale before you commit. The jobs list filtered by their email (@their@email.com) tells you what those jobs actually are.

One protection exists, and it is the only one. If the member owns a High-Performance Storage device with active jobs belonging to other users, Rescale prevents the deactivation rather than disrupting those users. Everything else proceeds.

Worth doing first:

  1. Check for running work and coordinate timing with whoever depends on it.
  2. Download their uploaded files. These are deleted whichever path you choose, and this is the only chance to keep them.
  3. Decide who inherits their workload files, if you are transferring. You choose during the flow.

Deactivate​

  1. Go to Workspace Admin > Teams > Members.
  2. Open the member. Deactivate Member is at the bottom of their page, under Team Actions.
  3. Click Deactivate Member.
  4. Choose what should happen to their files, then click Next.
  5. If you chose to transfer, pick the member who will receive the workload files. The list is searchable by name or email.
  6. Review the summary and type the member's email address to enable Confirm. Nothing is irreversible until you do.

Deleting is therefore two steps and transferring is three. Back moves you up the flow at any point without committing anything.

Classic UIThe first step. Read the small print on the transfer card: it moves workload files and deletes everything else.
If they are moving teams rather than leaving

Change Workspace, the other action under Team Actions, moves a member to a different workspace instead of deactivating them. It avoids this flow entirely and keeps their jobs, files and history intact, so prefer it whenever the person is staying with the company.

Option 1: Transfer workload files to another member​

Pick the member who should receive the files, searching the list by name or email. Their workload files, meaning the jobs and workstations, are transferred to that person. The departing member's uploaded files are deleted immediately on deactivation, and the selection step says so itself, so transferring is not a way of keeping everything on someone else's account.

Classic UIThe transfer confirmation separates what moves from what is destroyed. Uploaded files go immediately.

Option 2: Delete everything​

All of the member's data is permanently deleted: workload files and uploaded files alike. The deletion happens once their active workloads have finished shutting down, so it is not instantaneous, but it is not a recoverable window either.

Classic UIThe delete confirmation. The counts above the summary are the last chance to notice how much work is about to end.
Deletion is permanent, not a trip through the trash

This path does not put files in the workspace trash to be purged later under the file retention period. It deletes them outright once the workloads stop, so retention settings are not a safety net here and there is nothing to recover from.

What the receiving member gets​

The member you nominate becomes the assigned owner of the transferred jobs and workstations, and in practice they can work with them much as the original owner could: open them, download their files, share them with other users, archive and recover them, and delete run files. For day-to-day purposes the transfer gives them the access they need.

What does not move with the files is the ownership record itself, and that has one consequence worth planning around.

Storage for transferred data still bills against the departed member

Today, the storage consumed by transferred jobs and files continues to be attributed to the member you deactivated rather than to the assigned owner, and the Storage and Transfer Limits page and its CSV export report it under that original member too.

So the cost does not disappear and it does not follow the work. It accrues under the name of somebody who has left, which is the one place nobody reviewing storage spend thinks to look. Agree at the point of transfer who is responsible for pruning the data, because no usage report will prompt anyone to do it later.

Finding transferred jobs​

The receiving member uses the "Assigned to me" filter on the Jobs or Workstations page. That's the reliable way; transferred items also appear under "Any Owner", which is noisier.

To find them by the original owner, search @their@email.com. See find and manage your jobs.

What you can't recover​

Three one-way outcomes
  • Uploaded files are deleted on both paths. The transfer option covers workload files only, so anything uploaded outside a job or workstation goes. Download it before deactivating.
  • Performance Profiles and Workflows cannot be transferred. They aren't covered by either option.
  • The receiving member can't be changed afterwards — not without offboarding that person too, which starts the whole flow again. Choose carefully.

API keys and tokens​

A deactivated user's API key stops authenticating. Anything automated under their credentials (scheduled submissions, CI pipelines, integrations) breaks at deactivation.

This is the most commonly missed consequence. Before offboarding an engineer who built automation, find out what runs as them and reissue it under a surviving account.

The key itself is not destroyed, only refused, so a member who is later reactivated can authenticate with the same key again. That is a convenience and not a plan: it only applies where the account can be reactivated at all, and it does nothing for the automation that was failing in the meantime.

What the user sees​

Someone deactivated who tries to sign in with a password is told their account is inactive. They can't self-recover; an admin has to re-invite them.

Re-inviting someone you removed​

Behavior depends on whether their identity survived: see identity vs user:

Their identityRe-inviting
Still active — they're in another workspace, or weren't the last active userWorks normally; they regain access
Deactivated — they were the final active userThe old identity is gone. They're re-created as a new user, with no connection to their previous jobs or files.

So if someone might return, keeping them active in one workspace preserves the link to their history.

Deleting a whole workspace​

Deleting a workspace removes it, its users, and their data irrecoverably. It isn't an offboarding tool: see organizations & workspaces.