> 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/position-change.md).

# Position and role changes

Move someone to a new role, manager, or team, and have their access follow.

When someone moves — new job title, new manager, new team — their access should move with them. **Initiate Transfer** is how you start that, so the change is handled as one deliberate event rather than a series of ad-hoc requests.

Open it from **Requests → Create Request → Initiate Transfer**.

## Raising a transfer

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

The person who is moving.
{% endstep %}

{% step %}
**Select the new manager.**

Who they will report to afterwards. This matters beyond the org chart: their new manager becomes the approver for their future requests and the reviewer of their access.
{% endstep %}

{% step %}
**Enter the title.**

Their new job title. Access is often granted automatically from job title and department, so this is what drives the recalculation.
{% endstep %}

{% step %}
**Set the transfer start date.**

When the move takes effect. You can raise it in advance — a transfer dated for next month is processed then, not now.
{% endstep %}

{% step %}
**Set an end date, if the move is temporary.**

For secondments and cover arrangements. At the end date they revert, and access granted for the temporary role is removed automatically.
{% endstep %}

{% step %}
**Submit.**

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

## What happens to their access

This is the part worth understanding, because it is the difference between a clean move and a person who quietly accumulates permissions:

* **New birthright access is granted.** Access tied to the new department, title, or location is added automatically.
* **Old birthright access is removed.** Access that depended on the old position goes.
* **Individually granted access stays.** Anything given to them specifically — an exception, a one-off application — is not tied to their position, so it survives the move.

That last point is the one people miss. A transfer does not clear the slate. If someone has been granted things individually over the years, review them at the same time and remove what the new role doesn't need. See [Acting for your team](/end-user-guide-for-selfservice/your-team/direct-report-operations.md) for how to review their access.

{% hint style="warning" %}
Access accumulated across role changes is the single most common finding in access reviews. The moment someone transfers is the easiest time to clean it up — far easier than explaining it to an auditor a year later.
{% endhint %}

## Temporary moves

For cover and secondments, use the end date rather than planning to reverse it manually. Access that expires on a date is reliable; access that depends on someone remembering is not.

## If the transfer doesn't take effect

* **Check the start date.** A future-dated transfer processes on that date.
* **Check it was approved.** Look at [Request history](/end-user-guide-for-selfservice/requests/request-history.md).
* **Give it a little time.** Changes have to reach each system in turn.

If the date has passed, the request was approved, and their access still looks wrong, contact your help desk with the request number.


---

# 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/position-change.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.