> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/reference/user-lifecycle-reference.md). # User lifecycle reference The eleven lifecycle menu items with their resource IDs and audit actions; all 21 user statuses with what produces each; and the three properties that classify them. ## What this is, and when you need it Everything you scan rather than read when running a lifecycle action: which menu resource backs which button, which audit action proves it happened, and what each of the 21 user statuses means. The procedure itself is [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). ## The eleven lifecycle menu items All eleven are `MENU_ITEM` resources, members of the `USER_INFO_PAGE` resource, and granted to role `9` by the shipped data. Seven shipped in 3.2.6.0 and four more — **Terminate User**, **Deceased User**, **Leave With Pay** and **Leave of absence** — in 4.2.0.8. | Resource ID | English display name | Audit action | Resulting status | | -------------------------- | ------------------------ | ------------------------------- | -------------------------------------------------------- | | `RESET_ACCOUNT` | Reset Account | `USER_RESET_ACCOUNT` | `PENDING_INITIAL_LOGIN` | | `RESET_CHALLENGE_RESPONSE` | Reset Challenge Response | `USER_RESET_SECURITY_QUESTIONS` | unchanged | | `DEACTIVATE_USER` | DeActivate | `USER_DEACTIVATE` | `DEACTIVATED`, or `PENDING_DEACTIVATION` if future-dated | | `REMOVE_USER` | Delete | `USER_REMOVE` | `REMOVE`, or `PENDING_DELETE` if future-dated | | `ENABLE_USER` | Enable | `USER_ENABLE` | account enabled | | `DISABLE_USER` | Disable | `USER_DISABLE` | account disabled | | `ACTIVE_USER` | Active | `USER_ACTIVE` | `ACTIVE` | | `DECEASED_USER` | Deceased User | `USER_DECEASED` | `DECEASED` | | `TERMINATE_USER` | Terminate User | `USER_TERMINATE` | `TERMINATED` | | `LEAVE_WITH_PAY_USER` | Leave With Pay | `USER_LEAVE_WITH_PAY` | `LEAVE_WITH_PAY` | | `LEAVE_OF_ABSENCE_USER` | Leave of absence | `USER_LEAVE_OF_ABSENCE` | `LEAVE_OF_ABSENCE` | The audit action is the reliable identifier here, not the label: **DeActivate** and **Disable** read alike and record `USER_DEACTIVATE` and `USER_DISABLE` respectively, and only the first of them deprovisions. ### Each row carries a URL, and an upgrade can leave it stale Every one of these eleven menu items stores a **URL** that the user screen calls when the button is pressed. You can read and correct it at `/webconsole/editMenu` — find the menu item and open its properties; the field is **URL**. Two things about that value are worth knowing before you touch it. It is stored **without** a context prefix, because the user screen prefixes the application name itself — one row therefore serves both the Webconsole and SelfService. And release 4.2.1.10 re-based all eleven, so an instance that skipped it has values that are prefixed twice. **If you add your own lifecycle menu item, store its URL without a context prefix.** ### Three upgrade hazards on these rows Each of these is a row whose stored **URL** a particular upgrade path can leave wrong. Diagnose them by the symptom, not by the value — the second one is the dangerous case precisely because it does not look like a failure. | Row | Releases involved | What you observe | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DEACTIVATE_USER` | Seeded wrong in 3.2.6.0; 4.2.1.4 corrected the name and 4.2.1.10 re-based the path. An upgrade path that skipped either | **DeActivate** is present, and clicking it fails: no status change, no audit event, nothing in the targets | | `LEAVE_WITH_PAY_USER` | 4.2.1.10 pointed it at the leave-of-absence action; 4.2.2.0 corrected it. Any instance between those two releases | **Leave With Pay** reports success and sets status `LEAVE_OF_ABSENCE`, auditing `USER_LEAVE_OF_ABSENCE` instead of `USER_LEAVE_WITH_PAY`. No error at all — the status and the audit action are the only tell | | `RESET_CHALLENGE_RESPONSE` | Seeded with both a context prefix and a `.html` suffix; 4.2.1.10 corrected it. An instance that missed it | **Reset Challenge Response** alone fails while the other ten work | {% hint style="warning" %} **The console will show you the stored value but not what it should be.** `/webconsole/editMenu` lets you read and edit the **URL**, and comparing the eleven rows against an instance already at your target release is the reliable way to find the stale one. There is no screen that validates a menu item's URL or tells you the value the current release seeds, so if you have no reference instance, raise it with support rather than guessing — a wrong value fails silently, exactly as the three rows above do. {% endhint %} {% hint style="info" %} **Break-glass, read-only.** To see all eleven at once rather than opening eleven menu items, read the `URL` column of `RES` for those eleven resource IDs. It changes nothing and risks nothing, and it is the fastest way to spot the odd one out. Correcting a value belongs on the screen, in a change window, with the reasoning recorded. {% endhint %} ### Which dialogs offer which options | Dialog offers | Actions | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | A **Description** field | All but **Active**, **Enable** and **Disable** — those three record no narrative at all | | **Perform now?** and, when it is cleared, a **Start Date** | **DeActivate** and **Delete** only | | **Select applications to exclude from this action** | **Active**, **Enable** and **Disable** always; **DeActivate** and **Delete** only while **Perform now?** is ticked | The last row is a real constraint rather than a quirk: on **DeActivate** and **Delete** the exclusion list and the future date are mutually exclusive, because clearing **Perform now?** to reveal the date removes the exclusion control. See [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). ## The 21 user statuses These are the values the **Status** drop-down offers and the values stored on the user. The name on screen and the name in the column are the same text, so what you read in a break-glass query is what you read in the UI. | Status | Means | Produced by | | ------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------- | | `ACTIVE` | Normal, in service | **Active**; the normal end state of creation | | `INACTIVE` | Not in service, no lifecycle action pending | Set directly, or by an inbound synchronization | | `PENDING_START_DATE` | Created ahead of a future start date | Creation with a future start date; cleared by the `PROV_BY_START_DATE_FUT` batch task | | `PENDING_APPROVAL` | Creation or change awaiting an approver | New-hire and self-registration flows with approval | | `APPROVAL_DECLINED` | An approver rejected the request | An approval workflow outcome | | `PENDING_USER_VALIDATION` | Awaiting the subject's own confirmation | Self-registration with email validation | | `PENDING_INITIAL_LOGIN` | Credentials issued, never used | **Reset Account**; also creation with an activation link | | `TERMINATED` | Employment ended | **Terminate User** | | `DEACTIVATED` | Deprovisioned but retained | **DeActivate** executed now | | `REMOVE` | Marked for removal; accounts deleted in targets | **Delete** executed now | | `LOCKED` | Locked by failed authentication | Password policy lockout | | `LOCKED_ADMIN` | Locked deliberately by an administrator | Administrative lock, distinct from policy lockout | | `DISABLED` | Account disabled, identity retained | **Disable** | | `RETIRED` | Retired | Set directly, or by an inbound HR feed | | `LEAVE` | Generic leave | Set directly; counted as active by the shipped active-status list | | `PENDING_DELETE` | Removal scheduled for a future date | **Delete** with a future date | | `PENDING_DEACTIVATION` | Deactivation scheduled for a future date | **DeActivate** with a future date | | `DECEASED` | Deceased | **Deceased User** | | `LEAVE_WITH_PAY` | Paid leave | **Leave With Pay** | | `LEAVE_OF_ABSENCE` | Unpaid leave of absence | **Leave of absence** | | `PENDING_DISABILITY` | Disability process under way | Set directly or by an HR feed; no shipped menu item drives it | Five of these also exist as metadata types in the `USER` grouping, which is how they appear as **secondary** statuses in drop-downs: `DECEASED`, `LEAVE_WITH_PAY`, `LEAVE_OF_ABSENCE`, `PENDING_DEACTIVATION` and `PENDING_DELETE`. Confirm the list on your own build under **Administration → Metadata Types**, grouping `USER`. {% hint style="info" %} Nine of the 21 have no shipped menu item that produces them. `RETIRED`, `PENDING_DISABILITY`, `LOCKED_ADMIN`, `INACTIVE` and `LEAVE` are reachable by setting the status field directly, by a business rule action, or by an inbound synchronization. If your HR feed writes them, add them to the classification properties below or the screens that consult those lists will treat them as neither active nor inactive. {% endhint %} ## The three status classification properties All three are category `System`, at **Administration → System Configuration**. | Property | Label | Shipped default | | -------------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------- | | `org.openiam.ui.webconsole.active.user.status` | Active User Status | `ACTIVE,LEAVE,LEAVE_OF_ABSENCE,LEAVE_WITH_PAY,PENDING_INITIAL_LOGIN` | | `org.openiam.ui.webconsole.inactive.user.status` | Inactive User Status | `TERMINATED,INACTIVE,DECEASED` | | `org.openiam.ui.webconsole.prohibited.user.status` | Prohibited User Status from Self-Service | `TERMINATED,INACTIVE,DECEASED` on a fresh install — see below | ### The prohibited list's shipped value depends on your upgrade path This one catches people. When 4.2.1.12 introduced the key it took its value from an older, now-deleted flag that controlled whether terminated objects were searchable. If that flag had been set to `false`, the new key ships **empty**; otherwise it ships `TERMINATED,INACTIVE,DECEASED`. A fresh install has no old flag and gets the populated value. An upgrade from a system where terminated objects were searchable gets the empty one, and terminated users stay visible in SelfService. **Read the value** at **Administration → System Configuration**, category `System`, rather than assuming it. The prohibited list is applied **only** under `/selfservice`, and only when it is non-empty. In the Webconsole, terminated users remain findable whatever the list says — which is what you want for an administrator and not what you want for a directory lookup. Check it by searching for the same terminated user from both surfaces. ## Related * [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) — the procedure these values support * [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — retention for each `USER_*` action * [Shipped batch tasks](/administration-guide/reference/shipped-batch-tasks.md) — `DELETE_PENDING`, `LEAVER_PROCESS`, `PROV_BY_START_DATE_FUT` *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/reference/user-lifecycle-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.