> 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/end-user-guide-for-selfservice/your-team/leave-and-termination.md).

# Leave and termination

Handle someone going on leave or leaving the organization, including what happens to their mailbox.

When someone goes on extended leave or leaves altogether, their access needs handling deliberately — suspended while they're away, removed when they've gone.

Open **Leave / Termination Request** from **Requests → Create Request**.

## Raising the request

{% stepper %}
{% step %}
**Select the user.**
{% endstep %}

{% step %}
**Choose the type of leave or departure.**

The **Type of Leave / Departure** list is defined by your organization and typically distinguishes temporary absence — such as **Leave of Absence** or **Leave With Pay** — from a permanent departure.

The distinction matters: temporary absence suspends access, departure removes it.
{% endstep %}

{% step %}
**Set the return date, for temporary leave.**

When they're expected back. Access is restored then, so you don't have to remember to do it.
{% endstep %}

{% step %}
**Set how long to keep the mailbox open.**

**Keep Mailbox Open (Days)** decides how long their email remains accessible after they go. Organizations use this so a manager or colleague can retrieve work correspondence, and so messages aren't bouncing on day one.

Set it to what your organization's policy allows — this is often governed by retention rules rather than left to preference.
{% endstep %}

{% step %}
**Add a comment.**

Context for the approver and for the record.
{% endstep %}

{% step %}
**Submit.**

It goes for approval, and you can follow it in [Request history](/end-user-guide-for-selfservice/requests/request-history.md).
{% endstep %}
{% endstepper %}

## What happens to their access

**For temporary leave**, access is suspended rather than removed: the accounts remain, so nothing has to be rebuilt when they return on the date you set.

**For a departure**, one of two things happens, depending on your organization's configuration:

* **Access is removed** — roles and groups are revoked, and connected accounts are disabled or deleted.
* **Access is end-dated** — it stays in place with an expiry date rather than disappearing at once.

Either is a deliberate choice made by your organization. End-dating is often chosen so that work can be handed over cleanly.

As with any removal, applications OpenIAM connects to are updated automatically, while the rest generate a task for someone to action by hand — see [Giving up access](/end-user-guide-for-selfservice/requests/revoke-access.md).

{% hint style="warning" %}
Raise the request **before** the leaving date, not after. The gap between someone walking out and their access being switched off is exactly the risk this process exists to close — and it is the first thing an auditor measures.
{% endhint %}

## Before someone leaves

A short checklist that saves a great deal of trouble afterwards:

* **Hand over shared accounts.** Anything they alone could reach needs a new owner.
* **Reassign their approvals.** Otherwise requests queue behind someone who has left — see [Request administration](/end-user-guide-for-selfservice/approvals/request-administration.md).
* **Reassign their direct reports**, if they managed people, so those people still have an approver.
* **Agree who retrieves what** from their mailbox and files, within the days you set.

## If someone comes back

For temporary leave, access is restored automatically on the return date.

Someone returning after a full departure is normally treated as a new joiner — a fresh request, with access granted for the job they're returning to rather than the one they left. That is intentional: rejoining after a year should not silently restore the access they had before.


---

# 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/end-user-guide-for-selfservice/your-team/leave-and-termination.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.