> 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/identities/user-lifecycle-actions.md). # Run a user lifecycle action Deactivate, delete, enable, disable, activate, terminate, mark deceased or put a user on leave — immediately or on a future date — and prove the change reached the managed systems. ## What this is, and when you need it A lifecycle action changes a user's status and drives provisioning to every managed system the user has an identity on. Each action is a separate button, grant and audit action, so "the button is missing" and "the button did nothing" are different problems with different fixes. Two of the eleven buttons carry a far larger blast radius than their labels suggest. Read the table before you click. ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------ | | **You will end up with** | The user in the new status, and the matching change on each managed system | | **Where** | The action buttons on a user's record, under **User Admin → User Search** | | **You need first** | That action's menu grant, and a user you can afford to change | | **Takes** | Seconds to submit; provisioning is asynchronous | | **Reversible** | Partly — status changes reverse; deleted accounts and reset credentials do not | ## Choose the action | Button | What it does | Resulting status | Audit action | | ---------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------- | | **Active** | Returns the user to service and provisions | `ACTIVE` | `USER_ACTIVE` | | **Enable** | Enables the user's accounts; does **not** deprovision | account enabled | `USER_ENABLE` | | **Disable** | Disables the user's accounts; does **not** deprovision | account disabled | `USER_DISABLE` | | **DeActivate** | Deprovisions — issues delete operations to the managed systems | `DEACTIVATED`, or `PENDING_DEACTIVATION` if future-dated | `USER_DEACTIVATE` | | **Delete** | Marks the user for removal; accounts deleted in targets | `REMOVE`, or `PENDING_DELETE` if future-dated | `USER_REMOVE` | | **Terminate User** | Ends employment; end-dates or removes role and group memberships | `TERMINATED` | `USER_TERMINATE` | | **Deceased User** | As terminate, for a death in service | `DECEASED` | `USER_DECEASED` | | **Leave With Pay** | Paid leave. Leaves entitlements alone | `LEAVE_WITH_PAY` | `USER_LEAVE_WITH_PAY` | | **Leave of absence** | Unpaid leave. Leaves entitlements alone | `LEAVE_OF_ABSENCE` | `USER_LEAVE_OF_ABSENCE` | | **Reset Account** | Resets password, security questions and secret word | `PENDING_INITIAL_LOGIN` | `USER_RESET_ACCOUNT` | | **Reset Challenge Response** | Security questions only | unchanged | `USER_RESET_SECURITY_QUESTIONS` | {% hint style="danger" %} **"Delete" does not delete, and "DeActivate" is not "Disable".** The button labelled **Delete** sets the user's status to `REMOVE`. The OpenIAM record survives and the user stays findable in the Webconsole; the accounts on the managed systems may not. **DeActivate** deprovisions — OpenIAM issues delete operations to the managed systems. **Disable** does not. Run each once against a test user and compare the child audit events: the deactivate produces connector operations, the disable does not. {% endhint %} ## Run the action {% stepper %} {% step %} ### Open the user's record and pick the action The buttons on the user record are individually entitleable. If the one you want is not there, you do not hold its grant — the resource IDs are listed in [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md). {% endstep %} {% step %} ### Decide whether it happens now or later Only **DeActivate** and **Delete** offer a date. Their dialogs carry a **Perform now?** checkbox; clear it and a date field appears. The dialogs for the other nine act immediately and offer no date at all. The date field is labelled **Start Date** even though what it sets is the date the action takes effect. Read it as the effective date. A date in the past, or **Perform now?** ticked, or no date at all, all execute now. **Only a genuinely future date defers**, and deferring parks the user in `PENDING_DEACTIVATION` or `PENDING_DELETE` with your date recorded as the user's last date. {% endstep %} {% step %} ### If you are deferring, confirm the batch task that carries it out is enabled {% hint style="danger" %} **Nothing carries out a future-dated deactivation or delete unless a batch task is enabled.** The task is `DELETE_PENDING` — name "Delete/Deactivate by last Data", script `batch/deleteOnExpiration.groovy`, cron `0 0/30 * * * ?` — and it ships **disabled**. Confirm at **Administration → Batch Tasks**: the `DELETE_PENDING` row's **Enabled** column reads `N` on an unmodified install. On a shipped configuration, a future-dated deactivation parks the user in `PENDING_DEACTIVATION` forever. The save succeeded; the outcome never happens, and no audit event ever records that it did not. Enable `DELETE_PENDING` before you tell anyone that effective dating works on this instance, then prove it: future-date a deactivation on a test user for two minutes' time, wait for the next half-hourly run, and re-read the status. Two tasks that ship **enabled** are easy to confuse with it: `PROV_BY_START_DATE_FUT` ("Activate by Start Date", `0 0 0 1/1 * ?`) and `LEAVER_PROCESS` ("Disable by last date", `0 0 17 * * ?`). Neither executes a pending deactivation. See [Shipped batch tasks](/administration-guide/reference/shipped-batch-tasks.md). {% endhint %} {% endstep %} {% step %} ### Exclude any managed system that must be left alone The control is a multi-select placeheld **Select applications to exclude from this action**. Use it when an authoritative source — typically the HR system — must keep its record whatever happens in OpenIAM. Which dialogs offer it is not obvious, and one combination is impossible: | Action | When the exclusion list appears | | ----------------------------------- | ------------------------------------- | | **Active**, **Enable**, **Disable** | Always | | **DeActivate**, **Delete** | Only while **Perform now?** is ticked | | The other six | Never | {% hint style="warning" %} **On DeActivate and Delete you can have a future date or an exclusion list, never both.** Clearing **Perform now?** to reveal the date field removes the exclusion control from the same dialog. There is no screen path to "deactivate on the 31st but leave the HR system alone" — run it on the day with **Perform now?** ticked and the exclusion set, or accept that the deferred run will reach every managed system. {% endhint %} You pick managed systems from a list, so you cannot mistype one. What the list will not tell you is that a managed system with no resource behind it is **silently dropped** from the exclusion: the skip does not happen and nothing reports it. Verify by target state, never by the message on screen. {% endstep %} {% step %} ### Record why, in the dialog's Description field Whatever you type is stored on the audit event as the `DESCRIPTION` target attribute. It is the only narrative anyone will have when they ask, months later, why this person was deactivated. **Eight of the eleven dialogs have this field; three do not.** **Active**, **Enable** and **Disable** offer no **Description**, so those three actions leave an audit event with no narrative on it whatever you intended. If you need a reason recorded against an enable or a disable, put it somewhere that survives — a change record, or a user attribute — because the dialog will not take it. {% endstep %} {% endstepper %} ## Verification Verify the outcome, not the save. In order of increasing strength: 1. **Audit event.** The action's constant from the table above, at `/webconsole/auditLog`. Your description is on the event as the `DESCRIPTION` target attribute, and the target user is recorded as the user's primary principal on the default managed system. 2. **Stored status.** Reopen the user and read the status back. `PENDING_DEACTIVATION` or `PENDING_DELETE` means the action is *scheduled*, not done. 3. **Entitlements.** For terminate and deceased, confirm memberships are end-dated (the shipped default) or removed. 4. **Target state.** The account in each managed system, or its absence. This is the only evidence that the connector actually acted, and the only way to confirm a skip worked. {% hint style="info" %} Every one of these actions fires provisioning pre- and post-events, and a pre-processor can abort the action: OpenIAM then does nothing at all — no status change, no audit event, no error. If an action reports success and nothing happens, look for a pre-processor before you look anywhere else. See [Attach a provisioning processor](/administration-guide/lifecycle/provisioning-processors.md). {% endhint %} ## When it goes wrong | Symptom | Cause | Fix | | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The button is missing on the user page | You do not hold that action's menu grant. They are not bundled — **Disable** and **DeActivate** are separate grants | Grant the specific resource ID from [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md) | | The button is present and clicking it fails, with no status change and no audit event | The **URL** stored on that menu item is stale — an upgrade path that skipped the release which corrected it. Classically the **DeActivate** row | Read the row's **URL** at `/webconsole/editMenu` and compare it against a current instance. See [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md) | | **Reset Challenge Response** alone fails; the other ten work | That row still holds its pre-4.2.1.10 **URL**, which carries both a context prefix the screen adds a second time and a `.html` suffix that no longer resolves | Correct the row's **URL** at `/webconsole/editMenu` to the value the current release seeds, and re-test from both the Webconsole and SelfService | | A lifecycle button you added yourself fails on both surfaces | You stored its **URL** with a `/webconsole` prefix; the user screen prefixes the application name itself, so the prefix ends up doubled | Store the **URL** without any context prefix — one row serves both the Webconsole and SelfService | | **Enable** or **Disable** returns unauthorized despite the grant | Those two additionally require `USER_EDIT_INFO` **and** `ENABLE_USER`/`DISABLE_USER`, or that the target be your subordinate | Grant both operations, or rely on the subordinate path. See [Scope a delegated administrator](/administration-guide/identities/delegated-administration.md) | | A future-dated deactivation never executes | `DELETE_PENDING` ships disabled | Enable it at **Administration → Batch Tasks** | | A date was set but the action ran immediately | The date was in the past, or **Perform now?** was left ticked, or the date field was blank — all three run now | Clear **Perform now?**, then set a genuinely future **Start Date** | | Terminating from SelfService reports success but nothing changes | `org.openiam.workflow.termination.with.approver.association` is `true` and the request is awaiting an approver | Check the pending approval; the message you got was `USER_TERMINATE_VIA_APPROVER_WORKFLOW` | | An excluded managed system was provisioned anyway | That managed system has no resource behind it, so the exclusion was dropped silently | Confirm the managed system has a resource | | Entitlements gone after termination, when you wanted them end-dated | `org.openiam.workflow.termination.access.remove` was set to `true` | Set it back to the shipped `false`. Already-removed memberships are not restored | | A terminated user disappears from SelfService search | `org.openiam.ui.webconsole.prohibited.user.status` includes `TERMINATED` and is applied only under `/selfservice` | Expected. Search from the Webconsole — see [Find a user](/administration-guide/identities/find-a-user.md) | | A status set by an HR feed is treated as neither active nor inactive | Nine of the 21 statuses are in neither classification property | Add it to the appropriate property — see [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md) | | The action reported success but there is no audit event and no change | A provisioning pre-processor returned a break | See [Attach a provisioning processor](/administration-guide/lifecycle/provisioning-processors.md) | ## Roll it back **Enable / Disable / Active** — reversible. Run the opposite action. **Reset Account** — **not** reversible. It clears the IT policy approval date and the claim date, sets `PENDING_INITIAL_LOGIN`, clears the secondary status, and resets the password, the security questions and the secret word. The previous credential and the previous answers are gone. **DeActivate / Delete** — reversible with consequences. You can reactivate the OpenIAM user, but accounts deleted on managed systems are not restored by OpenIAM, and the target's own history is not restored either. **Terminate User / Deceased User** — reversible with consequences, and worse if `org.openiam.workflow.termination.access.remove` was `true`: end-dated memberships can be restored by clearing the end date, removed memberships must be re-granted by hand. **A future-dated action** — cancel it by changing the user's status away from `PENDING_DEACTIVATION` or `PENDING_DELETE` before the batch task runs. Clearing the last date alone is not sufficient; change the status. ## The exclusion list is honoured by two different mechanisms **Active**, **Terminate User**, **Deceased User** and the two leave actions treat an excluded managed system by leaving its resource out of the provisioning request. **DeActivate** and **Delete** pass the exclusion straight into the delete request instead. The distinction only matters when it fails: both mechanisms drop a managed system that has no resource behind it, silently and without an audit line, so both produce the same symptom — an account changed on a system you thought you had excluded. Confirm in the target. ### What a deferred action actually does, in order Future-dating is the case people misread most, so walk it once on a test user: 1. The dialog closes with a success message. **The request was accepted and nothing else has happened.** 2. The user's status is now `PENDING_DEACTIVATION` or `PENDING_DELETE`, and the user's last date is your date. Reopen the record and confirm both. 3. On the next `DELETE_PENDING` run after that date — *only if you enabled the task* — the action runs and the provisioning requests go out. 4. Only then is there anything to check in the managed systems. A user sitting in `PENDING_DEACTIVATION` a week after the date you set is the shape of a disabled `DELETE_PENDING`, not of a failed save. ## Termination behaves differently under SelfService `org.openiam.workflow.termination.with.approver.association` ships `false`, category `Workflow`. With the shipped value, termination is immediate from both the Webconsole and SelfService. Set it to `true` and a manager terminating a direct report **from SelfService** no longer terminates anybody: OpenIAM raises a termination approval request instead and returns the success message `USER_TERMINATE_VIA_APPROVER_WORKFLOW`. Termination from the Webconsole is unchanged. {% hint style="warning" %} Both paths show the operator a success message. The only difference is *which* message. If you turn this property on, tell your managers, or they will believe terminations completed that are actually waiting on an approver. The approver association is identified by the script named in `org.openiam.activiti.termination.access.approver.association.groovy.script`, shipped as `/bpm/CustomTerminationAccessApproverAssociationIdentifier.groovy`. {% endhint %} ### What terminate and deceased do to entitlements `TERMINATED` and `DECEASED` are the two statuses that touch entitlements. One property decides how: | Property | Shipped default | Effect | | ------------------------------------------------ | --------------- | ---------------------------------------------------------------------------------------------------------------- | | `org.openiam.workflow.termination.access.remove` | `false` | With `false`, memberships get today's end date and operation `REPLACE`. With `true`, they get operation `DELETE` | The shipped default preserves the audit trail of what the person had, which is normally what a certification or an investigation needs. Removing entitlements outright loses that. {% hint style="warning" %} Only **role and group** memberships are touched, by either setting. Resource entitlements and organization affiliations are not. If a terminated user must lose a directly granted resource, that is a separate revocation — either a business rule action such as `DROP_ALL_ENTITLEMENTS` or `END_DATE_ALL_ACCESS`, or the `AUTO_REVOCATION` batch task for end-dated access, which also ships disabled. {% endhint %} The leave statuses do not touch entitlements at all, which is the point of them. ## Related * [Grant and revoke access](/administration-guide/identities/grant-and-revoke-access.md) — the entitlements these actions end-date or remove * [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md) — the eleven menu items, the 21 statuses and the status classification properties * [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/identities/user-lifecycle-actions.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.