> ## Documentation Index
> Fetch the complete documentation index at: https://sofiedocs.usetransfer.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Deactivate and offboard users
> Block Sofie access, transfer a departing user's resources to an active successor, and monitor the offboarding process.
Deactivation blocks a user's access to Sofie without deleting their data. Offboarding then transfers the work they own or operate to one active successor.
Use deactivation first when someone leaves. Transfer their resources after the account is inactive. You can optionally delete the account after the transfer finishes.
Resource transfer runs in the background and cannot be undone automatically. Confirm the departing user and successor before you start it.
## Before you start
Confirm that:
* Your role includes **View Users**, **Deactivate Users**, and **Offboard Users**. You also need **Delete Users** if you plan to delete the account afterward.
* The successor is an active Sofie user.
* The successor is not the departing user.
* The successor is prepared to own the user's Workspaces, shared content, and automations.
* You have reviewed any organization process that applies to user departures.
Sofie does not let you deactivate or offboard your own account. These actions may require passkey confirmation.
## Understand account states
| State | What it means |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Active** | The user can sign in and use Sofie according to their role and access. |
| **Deactivated** | Sign-in is blocked. Sessions have ended. The account and its data remain intact for resource transfer or possible reactivation. |
| **Departed** | An administrator deleted the account after transferable resources were moved. The profile is hidden across Sofie. |
Use the **Active**, **Deactivated**, **Departed**, and **All** tabs in **User Management** to find accounts by state.
## Deactivate a user
Go to the administration area and open **Users**.
Open **Active** and find the person who should no longer have access.
Open the user's **Actions** menu and select **Deactivate user**.
Confirm that you selected the right person. Click **Deactivate User**, then complete passkey confirmation if prompted.
Open **Deactivated** and confirm that the user appears there.
Deactivation immediately:
* Blocks sign-in.
* Ends active sessions.
* Disables the user's connected integrations.
* Pauses automations that run as the user until their resources are transferred.
* Keeps the user's data and current ownership intact.
Deactivation does not transfer anything. Complete the offboarding transfer to give a successor ownership and operational responsibility.
## Transfer resources to a successor
In **User Management**, open **Deactivated**. Open the user's **Actions** menu and select **Manage user**.
In **Account Lifecycle & Offboarding**, review the resource types and counts. Only resource types with current items appear.
Under **Transfer everything to a successor**, choose an active user from **Select successor**. The list shows names and email addresses to help you distinguish similar users.
Click **Transfer ownership**. Review the confirmation, then click **Start Transfer**. Complete passkey confirmation if prompted.
Check **Transfer status** until it shows `completed`. The transfer continues in the background.
Confirm that **Owned resources** says the user has no transferable resources. Spot-check critical Workspaces, artifacts, shares, and automations with the successor.
If **Owned resources** says the user has no transferable resources, Sofie does not show the transfer controls. You can leave the account deactivated or delete it according to your organization process.
## What the transfer changes
Sofie handles resources according to how they are used.
| Outcome | Examples |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Ownership transfers | Workspaces, Workspace files and folders, Surfaces, CoDrafts and templates, CoSheets, Orchestrations, Orchestration tests, Sequences, Skills, Saved prompts, meeting types, and groups. |
| Operational responsibility transfers | Automations that run as the user and supported organization-level external chat or messaging connections are reassigned to the successor. |
| Access entries transfer or merge | Workspace memberships, collaborator roles, received shares, and Surface assignments move to the successor. If the successor already has the same access, Sofie merges the entries and keeps the stronger applicable role. |
| Personal data stays archived | Personal conversations and meeting recordings remain with the departed user's account. They are not assigned to the successor. |
| Historical attribution stays intact | Existing comments, revisions, activity, prior runs, and other history continue to identify the original user. |
| Personal access is disabled or revoked | Personal integration access, permission overrides, group membership, pending invitations, preapprovals, and similar user-specific grants do not transfer. |
The successor must connect their own accounts for integrations that require personal authentication. Reactivating the original user also requires them to reconnect integrations.
## Monitor and retry a transfer
**Transfer status** can show `pending`, `running`, `completed`, or `failed`.
* For `pending` or `running`, keep the departing user deactivated and the successor active.
* For `completed`, confirm that no transferable resources remain.
* For `failed`, review the error shown in **Account Lifecycle & Offboarding**. Correct the issue and retry with the same successor.
Do not choose a different successor when retrying a failed transfer. Some resources may already have moved, and Sofie requires the same successor to avoid splitting ownership between users.
## Reactivate a user
Reactivate an account when the person should regain Sofie access.
In **User Management**, open **Deactivated**.
Open the user's **Actions** menu and select **Reactivate user**. Complete passkey confirmation if prompted.
Ask the user to reconnect any integrations they still need.
Reactivation restores sign-in. It does not automatically restore integrations or reverse a completed resource transfer.
## Delete the account after offboarding
Deletion is optional. Use it only when your organization process calls for the user to move from **Deactivated** to **Departed**.
Sofie blocks deletion while the user still owns transferable resources. Complete the transfer first, then click **Delete User** from the user's details.
Deleting the user:
* Blocks sign-in and ends any remaining sessions.
* Hides the profile across Sofie.
* Moves the account to **Departed**.
* Keeps retained content and historical attribution intact.
Re-inviting the same email restores the account. It does not reverse resources that were already transferred to the successor.
## Offboarding checklist
Before you finish:
* The departing account is deactivated.
* **Transfer status** is `completed`.
* No transferable resources remain in **Owned resources**.
* The successor can open critical Workspaces and shared artifacts.
* Important automations have the expected new owner or run-as user.
* The successor has reconnected any required personal integrations.
* You deleted the account only if your organization process requires it.
Authorized administrators can review related access events in [Security Center](/admin/security-center).