> 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/faq/provisioning-and-lifecycle.md). # Provisioning and lifecycle Short answers to questions administrators ask most often about provisioning and lifecycle. ## What this is, and when you need it Short answers to the questions this area generates most often, each linking to the page that carries the detail. If your question is not here, the section hubs route by outcome and the [error and symptom index](/administration-guide/error-and-symptom-index.md) routes by the exact message you were given. ### A policy-map row is in the connector request but the value never appears in the target. Why? The row did its job and the managed system, or the connector, declined the value — so look at the request that was sent and at the target's own response, not at the policy map. The three usual causes are a custom attribute name the connector does not recognise and therefore drops at debug level, a value sent in the wrong form for a binary target attribute, and a naming collision with an object in the target that OpenIAM cannot see because its lookups return user objects only. Read the request body from the `provisionconnectorrequest` index and the reply from `connectorreply` before changing anything. [Full detail](/administration-guide/lifecycle/policy-map.md#when-it-goes-wrong) ### Why do concurrent provisioning operations fail with `ANOTHER_SAVE_IN_PROGRESS`, or mix up two users' data? Both symptoms come from scripts doing something the platform already does. A save takes a distributed lock named after the user ID, so a script that starts a second provisioning operation or save on the user the outer operation is already saving fails immediately — and when the save came from provisioning it is not re-queued, so the operation fails outright with no retry. Separately, one instance of each policy-map script is cached and shared across every user and thread on a node, so per-user state held in a script field leaks between concurrent operations. Mutate the object you were handed, return, and keep per-user data in local variables. [Full detail](/administration-guide/lifecycle/provisioning-processors/provisioning-processor-reference.md#nested-provisioning-and-the-user-save-lock) ### Why does disabling or enabling a user in the console not change the account in the managed system? OpenIAM users carry two statuses: the primary status shown as **User Status**, and the secondary status shown as **Account Status**. The Disable operation sets the secondary status to `DISABLED` and the Enable operation clears it to `null` — neither touches the primary status, and editing the primary status alone does not re-enable an account. The shipped `userAccountControl` policy-map row only fires when one of the two status diffs is dirty, so repeating an action the user is already in sends nothing at all, and the PowerShell `enabled` row never reads the secondary status, so Disable has no effect on a PowerShell-connected managed system until that script is replaced. [Full detail](/administration-guide/lifecycle/policy-map/policy-map-reference.md#status-changes-and-account-enablement) ### Why is a change my pre-processor makes to the user not saved? Most often the change carries the wrong operation. `UserAttribute` defaults to `NO_CHANGE`, and every attribute with a `null` or `NO_CHANGE` operation is stripped from the incoming user before the save, so an attribute added with the two-argument constructor is silently discarded even though the processor's own log line proves it ran. Set `AttributeOperationEnum.ADD` or `REPLACE` — they have identical effect — and never rely on `NO_CHANGE` to mean "keep this", which matters most for organization affiliations, where a `DELETE` also strips descendants and any ancestor left without another child affiliation. [Full detail](/administration-guide/lifecycle/provisioning-processors/provisioning-processor-reference.md#mutating-the-provisionuser-safely) *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/faq/provisioning-and-lifecycle.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.