> 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/getting-started-guide/lifecycle.md).

# Identity lifecycle POC

What the lifecycle proof of concept builds, its safety rules, and what must be true before you start.

Seven pages that prove the core value of OpenIAM against Active Directory: connect, import groups, import users with memberships, provision, and deprovision safely. Budget 3–5 hours.

## Entry criteria

Setup complete: healthy stack, HTTPS, Webconsole access, break-glass admin, and the lab from [Prepare your lab](/getting-started-guide/prepare-your-lab.md) (POC OU, test data, service account, connector installer verified on the Windows host).

## The rules

1. **Everything is scoped to the POC OU.** The managed system's search base, the connector's `PermittedDN`, and every sync query point at `OU=OpenIAM-POC,…` — never the domain root.
2. **Read before write.** [Import AD groups](/getting-started-guide/lifecycle/import-groups.md) and [Import users and group memberships](/getting-started-guide/lifecycle/import-users-and-memberships.md) both run with **Provision to target systems = No**. This matters because the shipped user sync example has it **enabled** — you will explicitly turn it off when you clone the config.
3. **Set `ON_DELETE = DISABLE` before the first write** (done in [Connect OpenIAM to Active Directory](/getting-started-guide/lifecycle/connect-to-ad.md), before any sync runs). Without it, OpenIAM's default on user delete is a `DELETE` operation against AD. Companies differ on how deletes should behave; `DISABLE` is the safe evaluation default and the common production choice.
4. **One deliberate write, one deliberate disable.** Provisioning is enabled in [Provision a test account to AD](/getting-started-guide/lifecycle/provision-test-account.md) for exactly one test account, and deprovisioning is tested in [Deprovision by disabling](/getting-started-guide/lifecycle/deprovision-disable.md) against that same account.
5. **Collect evidence as you go.** Each page's checkpoint names what to capture (counts, screenshots, AD state). [POC checklist and cleanup](/getting-started-guide/lifecycle/poc-checklist-and-cleanup.md) assembles it into the POC verdict.

## Objects you'll meet (30-second version)

* **Connector** — the bridge process (here: a Windows service) that executes operations against a target system. Talks to OpenIAM via RabbitMQ queues.
* **Managed system** — the definition of one target system instance: which connector, which host, which service account, which base DNs.
* **Synchronization configuration** — a job that pulls objects from a managed system (or CSV, etc.), transforms them with a Groovy script, and matches them to OpenIAM records.
* **Policy map** — per managed system, the attribute-by-attribute recipe for what OpenIAM writes to the target during provisioning.

If you want the fuller vocabulary before starting (user vs. identity, the entitlement model, reconciliation), the **Concepts** page in the main documentation's getting-started chapter is the best 10-minute read — this POC deliberately keeps concepts to the minimum needed per step.

Start with [Install the AD connector](/getting-started-guide/lifecycle/install-ad-connector.md).


---

# 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/getting-started-guide/lifecycle.md?ask=<question>&goal=<user_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.