> 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/solution-architecture/coexistence/lifecycle-across-a-governance-boundary.md). # Lifecycle events across a governance boundary Leavers and transfers when two platforms govern two halves of an estate — who detects, who acts, what the other platform mirrors, and the mutations a joiner-and-leaver design will not survive. ## What this is, and when you need it Everything on the other pages of this part assumes access is granted. This page is about access ending, and about people whose relationship with the organization changes shape rather than starting or stopping. While two platforms govern two halves of an estate, an event in one person's life has to produce the right action in both. The design decision is **which platform detects the event, which platform acts on which access, and what obligation the other one has** — and, for the harder cases, **which identifier survives the change**. Get the second one wrong and the person's history splits in two, which is expensive to repair and usually discovered by an auditor rather than by you. ## The decision | Model | What it buys | What it costs | | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Each platform runs its own lifecycle against its own estate, on its own HR signal** (recommended) | Every removal has an owner, an approval context and a reconciliation loop that expects it. The enterprise view is what proves both ran | Two processes to operate and two sets of timing to reconcile. A gap between them is possible and has to be measured rather than assumed away | | **One platform reaches into the other's applications, for terminations only** | Fast, and superficially safer — one signal, one action | Breaks the single-writer rule for the one operation where a missing approval record matters most. The owning platform's reconciliation sees an unexplained removal and may restore it | | **A shared termination service both platforms call** | One implementation of the rule | A third system with no governance model of its own, holding the most sensitive operation in the estate. It becomes the thing nobody will upgrade | | **Manual coordination — a checklist per leaver** | Nothing to build | Works at ten leavers a month and fails at a hundred. In a regulated estate the evidence is a signature rather than a record | **Each platform acts on its own estate, from its own authoritative feed.** The enterprise view is what demonstrates that both did — which is the second reason to build it early. ## The leaver The clean shape is: the platform fed by the HR system that holds the person's employment detects the event and removes the access it owns; the other platform detects the same event from its own feed, or from a feed derived from the first, and removes the access *it* owns. Neither reaches across. The enterprise view shows both sides closed, and that screen is the evidence. Two properties of that shape need designing rather than assuming. **The signal has to reach both platforms.** During coexistence there are usually two HR systems and each platform is fed by one. The person leaving is a leaver in one of them and simply absent from the other. If the second platform's population is derived from the first — which it often is, since the enterprise view already requires a feed — then the termination arrives as a change to the record it already holds. If it is not, you need an explicit feed for terminations, and it needs the same reliability as the joiner feed. A leaver process that depends on someone remembering to notify the other estate is not a control. **Timing has to be stated.** OpenIAM's leaver mechanics are date-driven and scheduled rather than instantaneous, and the shipped defaults are worth knowing before the design promises a number. The **Disable by last date** batch task ships enabled and runs daily at 17:00. **Activate by Start Date** also ships enabled, running at midnight; two housekeeping tasks — an authentication-state cleanup and a nightly risk sweep — ship enabled as well, and neither affects the leaver path. The tasks that handle the more aggressive cases — **Delete/Deactivate by last Data**, **Provision Deprovision on date**, revocation of end-dated access, and business-rule recalculation — all ship disabled and are enabled deliberately. A design that assumes same-minute removal across both estates is describing a system nobody configured. Where an immediate action is genuinely required, the mechanism is not a batch task at all: a synchronization's transformation rule can return a code that starts a workflow directly on the record it is processing, including the terminate-user and revoke-access workflows, both of which ship. That is the right lever for a security-driven termination, and it is worth designing before the first one happens rather than during it. ## The transfer A person moving between the two organizations is harder than a leaver, and it is the case most often left until it occurs. The reason it is hard is structural: **the person is a leaver in one HR system and a joiner in the other, usually with a new employee number**, and the two events are processed by two platforms that do not know they concern the same human being. Three decisions have to be made in advance. **Which identifier survives.** If the correlation key changes at the boundary, the identity fractures: the leaver process closes one record, the joiner process opens another, and the person's access history splits into two halves that no report will ever rejoin. The practical answer is that an enterprise-wide identifier survives and the HR system's own numbering does not — which is one more argument for minting a synthetic workforce identifier rather than adopting a payroll number. This is a Part 2 decision, and [Cross-organization federation](/solution-architecture/coexistence/cross-organization-federation.md) explains why the identifiers on the two sides do not have to match for the federation to work. **What happens to the access from the old side.** The answer is almost always that it ends, and the useful question is when. A transfer that removes the old access before the new access exists produces a person who cannot work; a transfer that leaves it in place indefinitely produces exactly the accumulated entitlement that certification exists to catch. Model an explicit overlap with an end date rather than leaving it to whoever notices. OpenIAM's shipped position-change workflow reviews and revokes access on a change of position, and business rules can end-date, restore, prolong or drop all of a person's access as an action, driven by expressions over the identity's own attributes — employee type, classification, status and secondary status, job code, organization affiliation, start and end dates. **Which organization the person belongs to afterwards.** A person's organizational affiliations are held on the identity, and exactly one of them is primary — the product rejects a second primary affiliation outright. Making the primary affiliation the thing that changes on a transfer, rather than the identity, is what keeps one person as one record. ## The mutations a joiner-and-leaver design will not survive The joiner, mover, leaver model is a teaching device, not an inventory. In an estate of any size the following are routine, and each one crosses the governance boundary in a coexistence programme. **Contractor to employee, and back.** The same person, the same work, a different employment relationship — and frequently a second record created by whoever onboarded them the second time. OpenIAM models the kind of person as a user type, and provides a conversion that changes the type on an existing user and can merge a second record's access into it in the same operation. The merge behaviour is deliberately not decided for you: the shipped conversion script is a stub that does nothing, because "make this contractor an employee and give them the access from their new-hire record" is a rule only the organization can state. Decide it, and decide it before the first conversion, because the alternative is two identities for one person and an orphan that outlives the programme. Contract populations also need routine end-date maintenance rather than exceptional handling. A manager can change a contractor's end date, change their reporting manager, and add or remove an entitlement, across a set of their own people at once, from the self-service contractor operations. That the end date is a first-class managed thing is the point: contractor access that has no end date is not contractor access. **The seasonal returner.** Somebody leaves in the autumn and comes back in the spring, into the same role, with the same manager. Treating each return as a new joiner accumulates identities, breaks tenure reporting and loses the certification history. Treating it as a rehire against the existing identity requires two things to be true: the correlation key must still match a person who has been gone for six months, and the leaver process must have disabled rather than deleted. That second point is a design decision with a date attached — how long a terminated identity is retained before it is removed — and it should be set by the returning population's longest normal absence, not by a storage argument. OpenIAM distinguishes a range of ending states, including terminated, deactivated, disabled, retired and the several forms of leave, which is what lets a return be a status change rather than a creation. **Leave of absence.** Neither present nor gone. The access decision — suspend everything, suspend the sensitive subset, or leave it alone — differs by jurisdiction and by the kind of leave, and it is a governance decision rather than a technical one. Name the states you will use and what each does to access, because the alternative is that long-term absentees keep full access indefinitely, which is the finding that turns up in every first certification campaign. **Concurrent relationships.** A person who is an employee of one organization and a contractor to the other at the same time. This is the case that most often defeats a design built around a single primary affiliation and a single employment status, and it is worth deciding explicitly whether your estate allows it. If it does, the two relationships need separate end dates and separate entitlement sets attached to one identity; if it does not, say so, and enforce it at the feed. ## What we recommend **Let each platform close its own estate, and make the enterprise view the proof that both did.** Resist reach-across for terminations, however reasonable it sounds in the moment. **Decide the transfer case before the first wave, not before the first transfer.** It will happen during the migration. Improvising it produces split identities, and repairing those is manual work against two systems. **Fix the surviving identifier in writing, jointly with the other organization.** This is the single decision on this page with no cheap remedy. **State the removal timing you actually have, not the one people assume.** The shipped leaver task runs once a day at 17:00 and several related tasks ship disabled. If the requirement is tighter than that, it is met by the workflow-initiating feed, and that has to be designed. **Design the mutations before the joiner.** Contractor conversion, rehire and leave are where a lifecycle design meets reality. A programme that has automated the joiner beautifully and has no answer for the returner has automated the easy tenth of the problem. **Set the retention period for terminated identities from the returner population, not from storage cost.** Deleting an identity that will be back in six months is how you acquire duplicate people. ## What OpenIAM does not do here * **OpenIAM has no cross-platform termination.** It removes the access it owns. Access owned by another platform is removed by that platform, and OpenIAM's view of it changes only when the next reconciliation runs. * **There is no transfer object.** A transfer is a change to an identity's attributes and affiliations, interpreted by rules and workflows you configure; the product has no built-in notion of a move between organizations with two HR systems. * **The shipped user-type conversion script does nothing.** Type conversion works; the decision about what access follows a conversion, and whether a second record is merged, is a script you write. * **Nothing reconciles two identities created for one person.** If the correlation key fails and a second identity is created, merging them afterwards is manual work — there is no de-duplication process. * **Several lifecycle batch tasks ship disabled.** A design that relies on end-dated access being revoked, or on business rules recalculating overnight, has to say that those tasks are enabled deliberately. * **A federation trust carries no lifecycle.** A leaver in one estate does not become a leaver in the other because the assertions stop arriving; the other estate's records still show the access. ## Related * [The enterprise view without duplicate governance](/solution-architecture/coexistence/the-enterprise-view.md) — the screen that proves both platforms closed. * [Cross-organization federation](/solution-architecture/coexistence/cross-organization-federation.md) — why the two estates' identifiers need not match. * Part 2, *Choosing your authoritative sources* — which feed is allowed to say a person has left. * *Advanced lifecycle patterns*, *Convert a user's type* and *Build a business rule* in the Administration Guide — the return codes, batch tasks and rule actions behind these patterns. *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/solution-architecture/coexistence/lifecycle-across-a-governance-boundary.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.