We recommend that users be disabled, rather than deleted, in case you need to audit their prior activity, history, and settings. A disabled user will have activity, history, and settings log information retained, while deleting a user will remove their corresponding information from activity, history, and settings logs.

Users can be disabled by directly editing the user's settings, or through a variety of automatic features: disabling inactive users, disabling users who have never logged in, or expiring a user's access on a specific date.

Automatically disabling user accounts is an important security practice, as "stale" or unused accounts are an attractive target for attackers.

Automatically Disable Inactive Users

Disabling logins for inactive users reduces the risk of unauthorized access to the system. Dormant accounts are often targeted by attackers. By disabling these accounts, you minimize the potential attack surface and enhance overall system security.

The recommended approach is to create a User Lifecycle Rule, which gives you more granular 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 should include Folder Admins or Site Administrators. For example, you may choose to disable password-based users after 30 days of inactivity, while allowing SSO users a longer duration. These rules override the older site-level setting and individual user-level options.

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 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 expiration dates for users ensures that access is granted only for the necessary period, which is particularly important when the user is associated with a limited-duration project or a contracting period.

Edit the user's Access expiration date setting to specify the date when the user will not be able to log in. This approach allows you to set an end date for users with a known project duration or other situation where a specific date makes sense.

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 are completed.

While setting up a new user account, you have the flexibility to specify a mandatory time window within which the user must perform their initial login. You can enter the number of days in the Number of days user must first login by field while creating a new user. Alternatively, you can set or modify this value by editing the user's setting Automatically disable this user if not logged in by this date. Note that 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 prescribed period will result in an automatic deactivation of the user account, and any configured authentication methods will be removed. This proactive approach ensures that newly created accounts are put to use by their intended recipients as intended. This option disables the affected accounts within 24 hours of the specified duration. As an example, during the user creation process, if you set the Number of days user must first login by as 10 days, and the user fails to log in within that timeframe, the system will automatically disable the account between the 10th and 11th day from the user creation date.

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 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. A site administrator must explicitly re-enable the account before the user may access the site.

While administrator users can create email notifications and share link notifications for disabled users, disabled users will not receive notifications emails.

Disabled users are not counted for billing purposes.

Your site's storage usage will not be reduced if you disable users. If the file or folder is stored in Files.com, it counts toward storage usage. User count and user's status has no relation to storage usage.

Share Links that were created by a user who has been deactivated are still available by default, and site administrators can still manage those links. Alternatively, enabling the Auto-revoke Share Links for deactivated users setting will ensure that all Share Links are automatically revoked when a user is disabled or deleted, eliminating the need for manual intervention.

Re-Enable a User

User accounts which are marked as disabled will have to be re-enabled by a site administrator. Files.com does not provide any automated re-enablement of users, since re-enabling a user needs to be examined carefully by a site administrator.

A user account can be manually re-enabled by changing the Account enabled toggle back to the active state and will take effect immediately.

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