Disabling & Re-enabling Users
Disabling a user immediately blocks login access while keeping the account, configuration, and historical context intact. This approach fits temporary access removal, incomplete onboarding, role transitions, or security reviews where permanent removal is not required.
Files.com supports manual, scheduled, automated, and programmatic methods for disabling users. These options allow Site Administrators and Workspace Administrators to apply access controls consistently while reducing the risk posed by unused or inactive accounts.
Users can be disabled by directly editing the user's settings, or through automatic features: User Lifecycle Rules, disabling inactive users, disabling users who have never logged in, or expiring a user's access on a specific date.
Access Removal and Dependencies
Disable an account when access must stop while you retain its settings for review or possible reactivation. Delete the account when it no longer has a purpose and you have reviewed its resources. For an account maintained by an identity provider, make the lifecycle change there and verify that the Files.com account is disabled or deleted. Blocking sign-in at the provider alone leaves existing Files.com sessions and separately issued credentials available. SCIM offboarding requires a successful deactivation or deletion request; the provider's provisioning logs and Files.com SCIM Logs show whether that request arrived. LDAP deprovisioning applies during the configured directory synchronization.
Review the account's API keys, SFTP/SSH keys, Group membership, delegated site access, notifications, Share Links, and owned resources. Disabling a parent-site account blocks its delegated Child Site access, including Child Site Administrator access. User-owned credentials depend on the account, while site-wide API keys are independent of the administrator who created them. Disabling or deleting that administrator is not a plan for revoking site-wide credentials.
The Parent Site's account and lifecycle policies continue to govern its users on Child Sites. Its Share Link auto-revocation setting covers their individually owned links across those Sites, even where delegated access was removed earlier. A Child Site's own setting applies to its native users. Resource Policy and Offboarding explains the distinction between removing a person's access and retiring the resources they leave behind.
Check workflows that depend on the account before removing access. The effects below distinguish user-owned Automations v1 from site- or Workspace-owned Automations v2 and explain the separate policy for revoking Share Links. User Lifecycle Rules enforce inactivity policies; they do not replace offboarding for a contract or project that has ended.
Effects of Disabled Users
Once a user is disabled/deactivated, they are not able to log in. An administrator authorized to manage that account must explicitly re-enable it before the user may access the site.
Administrators can create email notifications and share link notifications for disabled users, but disabled users will not receive notification emails.
A user-owned Automation v1 keeps its owner and continues to run with that owner's folder permissions while the account is disabled. Disabling the person's account preserves the workflow; during offboarding, disable the Automation to stop it or transfer ownership to keep it running under another owner's permissions. Automations v2 uses site or Workspace ownership, so disabling its creator or last editor does not change its execution identity.
A background copy, move, or delete accepted before the user was disabled may still run to completion.
Disabled users are not counted for billing purposes.
Disabling users does not reduce your site's storage usage. If a file or folder is stored in Files.com, it counts toward storage usage. User count and user status have no relation to storage usage.
Share Links owned by a user who has been deactivated remain available by default, and site administrators can still manage those links. Enabling the Auto-revoke Share Links for deactivated users setting automatically revokes the Share Links owned by that user when the user is disabled or deleted. Group-owned links remain available, including links created by that user, and need separate review during offboarding.
Disabling a user does not affect logging. User activity and settings logs remain intact after a user is disabled. Historical activity and configuration changes remain available and can still be reviewed in the logs.
Manually Disable a User
You can manually disable a user's account by editing the user's settings. This option takes effect immediately.
Site Administrators can disable users across the site, Workspace Administrators within their Workspace, and Partner Admins within their Partner. Group Admins need both the edit and enable/disable capabilities, and can act only on users whose Primary Group they administer.
The same scope and capabilities apply when re-enabling an account. Group Admin capabilities never allow disabling or re-enabling accounts with Site Administrator, Read-only Site Administrator, or Workspace Administrator access on the Group Admin's own site, even with a matching Primary Group. Restrictions on manual management of provisioned users still apply.
Site Administrators can disable other Site Administrator accounts without first removing their administrative access. The disabled account cannot sign in, but keeps its Site Administrator status; re-enabling the account restores access with that status intact.
The web app does not display the Account enabled toggle for Site Administrator accounts. A Site Administrator can disable or re-enable these accounts through the API, an SDK, or the CLI.
Programmatically Disable Users
You can also disable user accounts programmatically with the CLI or SDKs.
Set an Access Expiration Date in the User's Settings
Assigning an expiration date grants access only for the period the user needs it, which matters when the user is associated with a limited-duration project or a contracting period.
Edit the user's Access expiration date to specify the date after which the user cannot access the site. Administrators with permission to create or edit the user's account can set this date, including Group Admins with the relevant capability for an eligible user's Primary Group, so access ends automatically on a defined date.
Group Admins cannot set an access expiration date on accounts with Site Administrator, Read-only Site Administrator, or Workspace Administrator access on their own site. Child Site Administrator access does not exclude an otherwise eligible parent-site account from this control.
When the access expiration date passes, Files.com immediately refuses new sign-ins, ends the user's existing login sessions, and stops access through the user's API keys and SSH keys, just as when the user is disabled.
The web interface can show Pending Disable until a separate automated process, which runs every few hours, marks the account Disabled. Pending Disable describes only the displayed account status; the user's access has already ended.
Automatically Disable Newly Created Inactive Users
Automatically disabling newly created users who have never logged in within a reasonable timeframe is a good security practice and a safeguard that your onboarding procedures get completed.
When setting up a new user account, you can specify a mandatory time window within which the user must perform their initial login. Enter the number of days in the Number of days user must first login by field while creating a new user.
You can also set or modify this value by editing the user's Automatically disable this user if not logged in by this date setting. This setting only applies to new users who have never logged in to the system at least once.
Once it is set, failure to log in within this period will result in automatic deactivation of the user account.
The Files.com platform runs a separate automated process to update the status of user accounts. The automated process runs every few hours, leaving a small time gap between the user's required first login date and the user's account indicating the status is Disabled. During this short period, the web interface shows that the user's status is Pending Disable, and they are blocked from logging in.
Automatically Disable Inactive Users
Disabling inactive accounts removes access that may no longer be needed. Otherwise, an unused account retains its permissions even after the person or integration has stopped using it.
The recommended approach is to create a User Lifecycle Rule, which gives you finer control over how inactive user accounts are handled at the site level. You can define rules based on authentication method, number of inactive days, and whether the rule includes Folder Admins or Site Administrators.
For example, you can disable password-based users after 30 days of inactivity while leaving SSO user lifecycle management to the identity provider. Lifecycle rules and individual deadlines apply independently: reaching an inactivity threshold, missing a required first-login deadline, or reaching an access expiration date can each restrict the user. Keeping an account active does not extend its fixed expiration date.
In some cases, you may want to prevent a particular user from being disabled or deleted due to inactivity. To do this, you can bypass User Lifecycle Rules for that user.
Re-Enable a User
Re-enabling a user restores access under the account's existing permissions. Before doing so, an administrator authorized to manage the account should review why access ended and whether it should be restored. Site Administrators, Workspace Administrators, Partner Admins, and appropriately enabled Group Admins can re-enable users within their respective scopes.
For accounts other than Site Administrators, changing the Account enabled toggle back to the active state immediately re-enables the account. Site Administrator accounts are re-enabled through the API, an SDK, or the CLI.
User Lifecycle Rules rely on a user's Last Active At time to measure inactivity. Re-enabling a user resets their Last Active At time, regardless of how long the account was previously disabled or inactive. For example, a user account that has been disabled for 29 days and is then re-enabled is considered "0 days inactive" by a 30-day inactivity rule.
You can also enable user accounts programmatically with the CLI or SDKs.
Deleting Disabled Users
Site Administrators or Workspace Administrators can configure the Delete disabled users after a time period setting to automatically remove user accounts that have been disabled for a certain number of days.