User Lifecycle Rules automatically disable or delete user accounts after a defined number of inactivity days, enforcing security and compliance requirements for dormant accounts. Accounts that remain active but unused retain permissions long after access is no longer required. Over time, these accumulate as stale or "ghost" accounts that remain active without a clear owner.

Site Administrators and Workspace Administrators can create User Lifecycle Rules for users within their respective scope.

Enable lifecycle rules only when required to meet security policies, compliance controls, or internal governance requirements for 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 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 will disable or permanently delete accounts unintentionally.

Different types of users often exist in the same environment. Internal users typically authenticate through SSO and are provisioned through SCIM. External users 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 remain inactive for extended periods while still being required. Exclude these accounts if inactivity thresholds would disable them unintentionally.

Lifecycle rules support inactivity thresholds of up to 10,000 days. 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.

Use the filtering options to scope each rule to the right users. Filter by authentication method, group membership, user tags, or partner tags, and exclude Site Administrators, Folder Admins, or Workspaces when those accounts must remain outside lifecycle enforcement. For SSO environments, setting User Authentication Method to All Non-SSO is the simplest way to keep SSO users out of scope.

Do not use lifecycle rules to manage partner onboarding, vendor offboarding, project timelines, contractual access periods, or temporary enable and disable workflows. Lifecycle rules enforce inactivity policies; they are not a mechanism 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 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 to specific users. Use these filters to apply lifecycle enforcement only to the intended users.

Rules can target users based on authentication method, group membership, user tags, or partner tags.
Rules can exclude SSO users by setting User Authentication Method to All Non-SSO.
Rules can also exclude Site Administrator, Folder Admins, and Workspaces.

Disable and Delete Actions

Lifecycle rules 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. To delete users who are already disabled, set User State to Disabled and configure the number of disabled days after which users will be deleted. This setting ignores the inactivity period. The two-stage configuration creates a review window before permanent removal.

For example, to disable users after 30 days of inactivity and delete them 30 days after being disabled, configure two rules: one to disable users after 30 inactivity days and one to delete disabled users after 30 days.

By default, User Lifecycle Rules skip Site Administrators, Folder Admins, and Workspaces. To apply a rule to any of these accounts, select them explicitly when creating or updating the rule. This prevents routine lifecycle enforcement from accidentally disabling or deleting privileged users and Workspaces.

Notifying Users Before a Rule Fires

The Notify Users setting on a lifecycle rule sends warning emails to users before a disable or delete action runs against their account. This gives users advance notice so they can sign in, which resets their inactivity period and prevents the rule from firing against them.

Warning emails follow a fixed cadence: notifications go out at 28, 14, 7, and 1 day before the rule fires. Only intervals that fall within the rule's inactivity period are sent. For example, a 10-day rule sends only the 7-day and 1-day warnings.

Notify Users is off by default. Enabling it does not change which users match the rule - existing targeting, group membership, tags, admin inclusion, and authentication method behavior all remain the same. The notification cadence, email template, and recipient address are not configurable. All notifications use the site's branding and go to the affected user's account email address.

Site Administrators and Workspace Administrators can audit which lifecycle rules have Notify Users enabled.

SSO and SCIM Environments

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. If a lifecycle rule disables or deletes an SSO user in Files.com, the rule only affects the account in Files.com. The SSO provider or identity provider (IdP) still maintains the user as active.

When configuring User Lifecycle Rules, review the User Authentication Method scope carefully. Selecting All includes SSO users along with every other authentication method, creating a second lifecycle control point outside the identity provider and leaving user status inconsistent between systems. If your organization uses SSO, set User Authentication Method to All Non-SSO. The rule then applies to every authentication method except SSO users.

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, causing Files.com and the identity provider to maintain different lifecycle states for the same user. A lifecycle rule will 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 on the user details page 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.