Processing of 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 creation date older than expiration period of applicable rule.

Inactivity period rules:
Applied to the users with last activity date older than 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 last activity date by a site level rule, but is not expired by a user level rule – effective rule is that a user is not expired.

Conflict resolution for the User group rules:
In scenarios when a user is a member of the two user groups which 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 user was expired by more than one rule with different action (deactivation and deletion), deactivation is selected over the deletion and expiration date of the rules is ignored.

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