User state transitions
The table below details possible user state transitions initiated by an operator, auto-archive rule, node activity, or directory sync.
| Transition state set by | initial state | action | Transition state |
|---|---|---|---|
| Operator |
|
The user is manually prevented from being auto-archived (see Preventing auto-archiving of users). |
Always active |
|
The user is manually unarchived (see Manually archiving and unarchiving users). |
Always active | |
|
The user is manually archived (see Manually archiving and unarchiving users). |
Archived | |
|
The user is manually deleted (see Deleting users). |
Deleted | |
| Auto-archive rules |
|
The user is auto-archived by the "inactive users" rule (see Auto-archiving inactive users). |
Archived |
|
The user is auto-archived by the "inactive users pending enrollment" rule (see Auto-archiving inactive users). |
Archived (never enrolled) | |
|
The user is auto-archived by the "directory-deleted users" rule (see User archiving and deleting). | Archived | |
|
The user is auto-archived by the "directory-deleted users" rule (see User archiving and deleting). | Archived (never enrolled) | |
| Node activity |
|
A node associated with the user sends a heartbeat to FortiDLP. |
Active |
|
A node sends a heartbeat to FortiDLP when it is enrolled, forming an association with the user. |
Active | |
| Directory sync |
|
The user is manually restored via the FortiDLP API after they were deleted (see User archiving and deleting). | Archived (never enrolled) |
|
The user is auto-unarchived because they were re-synced to FortiDLP after they were either auto-archived by the "directory-deleted" users rule or were manually restored (see User archiving and deleting). | Pending enrollment | |
|
The user is auto-unarchived because they were re-synced to FortiDLP after they were auto-archived by the "directory-deleted" users rule (see User archiving and deleting). | Active |