Processing expiration rules

Expiration rules are processed by the "User Expiration" microservice running on a schedule.

Processing of the expiration rules implements the following logic:

Fixed period rules:
Applied to the users with a creation date older than the expiration period of the applicable rule.

Inactivity period rules:
Applied to the users with a last activity date older than the expiration period of the applicable rule.
The last activity date is defined as the latest date between the following fields:

• DateReactivated – the date of the last user reactivation.
• RetentionUserDateLastActivity – date of the last file system operation by the user.
• DateLastLogin – the date of the last login by the user

Expiration rules are processed in the following priority:

• Priority 1: User level
• Priority 2: User group level
• Priority 3: Site level

Example: If a user should be expired based on the last activity date by a site-level rule but is not expired by a user-level rule, the effective rule is that the user is not expired.

Conflict resolution for the User group rules:
In scenarios when a user is a member of two user groups that have different user expiration rules, the following processing logic applies:
If a user was not expired by at least one rule, we consider the user not expired.
If a user expires by more than one rule with different actions (deactivation and deletion), deactivation is selected over deletion, and the expiration date of the rules is ignored.

Example: User group rules Delete after 10 days and Deactivate after 20 days—only the Deactivate rule is used.