User Lifecycle Rules

User Lifecycle Rules automatically disable or delete user accounts after a defined number of inactivity days to help enforce security and compliance requirements related to dormant accounts. Accounts that remain active but unused can retain permissions long after access is no longer required, and over time these accounts accumulate and create stale or “ghost” accounts that remain active without a clear owner.

User Lifecycle Rules enforce inactivity policies automatically. When an account exceeds the configured inactivity threshold, access is removed by disabling or deleting the account. This automation reduces the need for manual reviews of inactive users and helps ensure unused accounts do not remain active indefinitely.

Enable lifecycle rules only when required to meet security policies, compliance controls, or internal governance requirements for managing dormant accounts. Do not use lifecycle rules as a general mechanism to disable users.

Lifecycle rules evaluate inactivity only. They do not account for partner relationships, vendor access arrangements, scheduled file exchange processes, or other operational contexts that may still require an account.

Considerations Before Creating Lifecycle Rules

User Lifecycle Rules apply automatically to all users within their defined scope. If scope or inactivity thresholds are configured incorrectly, the rule can disable or permanently delete accounts unintentionally.

Different types of users often exist in the same environment. Internal users may authenticate through SSO and be provisioned through SCIM. External users may authenticate with passwords or SSH keys to access partner file exchanges, vendor integrations, or contractor workflows. Apply lifecycle rules only to the users that require inactivity enforcement.

Service accounts, integration users, and automation accounts require additional consideration. Accounts that run periodic integrations, scheduled synchronization jobs, or other infrequent processes may remain inactive for extended periods while still being required. Exclude these accounts if inactivity thresholds could disable them unintentionally.

Lifecycle rules support inactivity thresholds of up to 10,000 days. We chose this number to provide the greatest flexibility. Configure thresholds based on actual usage patterns, internal policy, or compliance requirements.

Do not apply Files.com User Lifecycle Rules to SSO users or users provisioned through SCIM. The identity provider manages the lifecycle of SSO users and controls when those users become active, inactive, or removed.

Do not use lifecycle rules to manage partner onboarding, vendor offboarding, project timelines, contractual access periods, or temporary enable and disable workflows. Lifecycle rules are intended for enforcing inactivity policies, not for temporarily disabling and re-enabling users.

How Lifecycle Rules Work

Each lifecycle rule defines the action to take, the inactivity period, and the authentication methods it applies to. Rules can apply different inactivity thresholds depending on how users authenticate.

When lifecycle rules are active, they override individual user settings, including Automatically disable this user if not logged in by this date and Access expiration date.

When a user reaches the defined inactivity threshold, login is blocked immediately. Files.com runs a background process every few hours that updates the user account status. During the short interval between reaching the inactivity threshold and the status update, the account displays Pending Disable and the user cannot sign in.

Filtering and Targeting Rules

Lifecycle rules can be scoped so they apply only to specific users.

Rules can target users based on authentication method, group membership, user tags, or partner tags. Rules can also exclude Site Administrators and Folder Admins.

Use these filters to ensure lifecycle enforcement applies only to the intended users.

Disable and Delete Actions

Lifecycle rules can either disable or delete user accounts.

Disabling removes login access while preserving the user account so it can be reviewed or reactivated.

Deleting permanently removes the user account, though deleted users can be restored. Restoration is intended for exceptional situations. Frequent restores usually indicate that User Lifecycle Rules are configured incorrectly or too aggressively, or that the inactivity period is set too short.

A common approach is to disable users after a defined inactivity period and delete them only after they remain disabled for an additional period. This creates a review window before permanent removal and helps ensure inactive accounts are eventually cleaned up.

SSO and SCIM Environments

If a lifecycle rule disables or deletes an SSO user in Files.com, the rule only disables or deletes the user in Files.com. The SSO provider or identity provider (IdP) still maintains the user as active.

Do not apply Files.com User Lifecycle Rules to SSO users. The identity provider manages the lifecycle of SSO users and controls when those users become active, inactive, or removed.

When configuring lifecycle rules, review the User Authentication Method scope carefully. Selecting All includes users authenticated through SSO along with other authentication methods. This configuration can unintentionally apply lifecycle rules to SSO users.

If your organization uses SSO, create separate lifecycle rules for specific authentication methods instead of selecting All. Apply lifecycle rules only to locally managed authentication methods and exclude SSO users.

Applying lifecycle rules to SSO users introduces a second lifecycle control point outside the identity provider and can create inconsistent user status between systems.

SCIM provisioning makes the identity provider the authoritative source for user lifecycle state. Files.com updates user status based on lifecycle state received through SCIM. Applying lifecycle rules in Files.com creates a second lifecycle control point outside the identity provider and can cause Files.com and the identity provider to maintain different lifecycle states for the same user. A lifecycle rule can disable a user in Files.com while the identity provider still marks the user as active.

When SCIM provisioning manages users and the setting Allow manual creation, editing, and deletion of users outside of SSO based provisioning is disabled, administrators cannot re enable a user directly in Files.com after a lifecycle rule disables that account. The identity provider must send an updated active state through SCIM provisioning before Files.com reactivates the user.

Excluding Individual Users

Individual users can be excluded from lifecycle rules.

The Prevent this user from being disabled due to inactivity setting from any user details excludes a user from all current and future lifecycle rules.

Use this safeguard for service accounts, automation users, integration accounts, and other accounts that must remain active regardless of inactivity.