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 in that authoritative system and verify the result in Files.com.

Review the account's API keys, SFTP/SSH keys, Group membership, delegated site access, notifications, Share Links, and owned resources. 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.

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.

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.

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. Restrictions on manual management of provisioned users still apply.

Site Administrator user accounts cannot be disabled. To disable a site-administrator's account, you must first revoke their administrator privileges.

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 log in. Administrators with permission to create or edit the user's account can set this date, including Group Admins with the relevant capability for the user's Primary Group, so access ends automatically on a defined date.

Users whose access is due to be disabled by an expiration are immediately prevented from logging in. The Files.com platform runs a separate automated process to update the status of user accounts. That process runs every few hours, leaving a small time gap between the user's expiration date taking effect 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 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.

Programmatically Disable Users

Our Command Line Integration (CLI) App and SDKs can also be used to programmatically disable user accounts.

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.

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 cannot run using a disabled owner's permissions. Review those workflows before disabling a Folder Admin. Automations v2 uses site or Workspace ownership, so disabling its creator or last editor does not change its execution identity.

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 created 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 all Share Links when a user is disabled or deleted, so no manual cleanup is needed.

Disabling a user blocks all access but 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.

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.

A user account can be manually re-enabled by changing the Account enabled toggle back to the active state, which takes effect immediately.

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.

Our Command Line Integration (CLI) App and SDKs can also be used to programmatically enable user accounts.