Deleting a user removes the account and blocks its access. This action is appropriate for final off-boarding scenarios where the account no longer has a valid purpose and restoration is not expected. Deletion provides a clear end state for access management and prevents inactive or obsolete accounts from remaining in the environment.

Site Administrators can delete users directly. Workspace Administrators can delete users within their Workspace. Partner Admins can delete users within their own Partner. Group Admins can delete users whose Primary Group they administer when the site-wide deletion capability is enabled, except for accounts with Site Administrator, Read-only Site Administrator, or Workspace Administrator access on the Group Admin's own site. A Group Admin cannot delete those administrator accounts on that site, even with a matching Primary Group and deletion enabled. Users can also be deleted through the API/SDKs or CLI, through identity provider–driven de-provisioning using SCIM or LDAP, or through automated User Lifecycle Rules. In all cases, login access is removed immediately.

User Lifecycle Rules provide automated control over deleting inactive or disabled accounts. These rules evaluate users based on authentication method, inactivity duration, group membership, tags, or Partner association. Lifecycle rules can first disable accounts and later delete them after a defined retention period, allowing time for review while enforcing consistent cleanup.

Preparation for Deletion

For an account maintained by an identity provider, remove access through that system and verify the result in Files.com. Review the account and credential dependencies before deletion, including any site-wide API keys that remain independent of the account.

Deleting a parent-site account also ends its delegated Child Site access, including Child Site Administrator access. That grant does not prevent a Parent Site Group Admin with the deletion capability from deleting an otherwise eligible account whose Primary Group they administer. The resource effects below determine what must be reassigned or retired.

Removing an entire Partner deletes its associated users. Removing a Workspace affects all of its resources as well as its users. Choose those broader operations only when the entire organization or environment is being retired.

Manual User Deletion

Site Administrators, Workspace Administrators, Partner Admins, and Group Admins with the deletion capability can delete a user within their respective scope. A re-authentication prompt appears to confirm the deletion. When a Site Administrator deletes a user manually, they can choose what to do with resources owned by the deleted user, including Share Links, Automations v1, GPG Keys, Remote Servers, Custom Forms, or folder settings. The Site Administrator can either reassign these resources to another user to help maintain visibility and control, or leave them without an owner if reassignment isn't needed.

You can also delete user accounts programmatically with the CLI or SDKs.

Automatic User Deletion

Users provisioned through LDAP or SCIM can be de-provisioned through the same LDAP or SCIM system used for provisioning.

User Lifecycle Rules enable automatic deletion of inactive users based on authentication method and inactivity duration. If a rule is configured with the delete action, eligible users will be removed, even if they were not previously disabled through other settings.

Disabled user accounts can also be automatically deleted using User Lifecycle Rules, which remove accounts that have remained disabled for a specified number of days.

When a user is deleted automatically through any of these methods, their resources are not deleted and are not assigned to a new owner. Site Administrators can manage the retained resources. User-owned Automations v1 are disabled when their owner is deleted without reassignment; other retained resources have the effects described below.

Effects of Deleting a User

Deleting a user account removes their login access but does not automatically delete the resources they own. If the user is deleted automatically through a User Lifecycle Rule, LDAP or SCIM provisioning, or automatic removal of disabled users, their login access is removed but their owned resources remain and are not reassigned. When deleting the user manually or through the CLI, the site administrator has the option to reassign those owned resources to another user or leave them without an owner.

When deleting the user account, the Site Administrator can choose to revoke Share Links created by the user, assign them to another user, or orphan them. Orphaned links have no owner; they remain active and continue to be manageable by Site Administrators.

Automations, GPG Keys, Remote Servers, and Custom Forms

Site Administrators can assign Automations v1, GPG Keys, Remote Servers, and Custom Forms to another user or choose to orphan them while deleting the user. Orphaned GPG Keys, Remote Servers, and Custom Forms remain functional without an assigned owner. A user-owned Automation v1 is disabled when its owner is deleted without reassignment. Reassign needed workflows before deleting the account, then review v1 ownership and security, because the new owner determines their execution permissions.

Automations v2 belongs to the site or a Workspace, rather than an individual user. Deleting the user who created or last edited a v2 Automation does not change its ownership or execution permissions.

Files and Folders

Deleting a user does not remove their stored files or folders. Storage usage and access remain unaffected unless folder permissions are modified.

Folder Settings and Notifications

Folder settings configured by the deleted user will remain in effect. Notifications set for the deleted user will no longer function. Folder settings can be reassigned to a new owner when deleting the user.

User Activity and Logs

User activity and settings change logs are retained even after a user is deleted. After deletion, the username continues to appear in the logs in italics to indicate that the account no longer exists, but those logs cannot be filtered by username until the user is restored.

Storage Usage

Deleting a user does not reduce your site's storage usage. Files and folders stored in Files.com continue to count toward storage regardless of user status. User deletion affects access and ownership only and has no impact on storage consumption.

Restoring a Deleted User

Deleted users can be recovered by a Site Administrator without contacting support. Review recovered credentials and permissions before returning the account to service. Restoring a user brings the account back with its settings, authentication methods, and API keys intact, without requiring the account to be recreated from scratch. For full details on how restoration works, what is recovered, and how to submit a restore request, see Restoring Users.

Deleting Users