> 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/for-managers/new-user.md).

# Creating a user

Raise a request to create an account for a new person.

**New User** raises a request to create an account for someone who doesn't have one — a new joiner, a contractor, a partner.

Open it from **Administration → New User**.

## Before you start

Have these ready:

* their **full name** as it should appear officially
* their **email address**
* their **start date**
* their **job title and department**
* who their **manager** will be
* what **access** they need on day one

The last point is worth thinking about before you start rather than during. If your organization has an [access profile](/end-user-guide-for-selfservice/your-access/access-profiles.md) for the job, that answers it in one step.

## Creating the request

{% stepper %}
{% step %}
**Fill in their details.**

Required fields are marked, and the form tells you what's missing — for example *"First name is a required field"* or *"Organization is a required field"*.

You are first asked what kind of person you are creating — employee, contractor, and so on. This choice matters: user type often decides what access they receive automatically.

Then fill in their details.

Take particular care over the email address: it's where their sign-in details are sent, and a typo means a new joiner with no way in on their first morning.
{% endstep %}

{% step %}
**Set their manager and job details.**

These drive birthright access — the access they receive automatically because of the job. Getting the department and title right here saves several requests later.
{% endstep %}

{% step %}
**Add the access they need.**

Attach an access profile if one fits, or select individual items.
{% endstep %}

{% step %}
**Submit.**

The request goes for approval like any other. Track it in [Request history](/end-user-guide-for-selfservice/requests/request-history.md).
{% endstep %}

{% step %}
**They receive their sign-in details.**

Once approved and created, their user name and password are sent to the email address you entered. See [Signing in](/end-user-guide-for-selfservice/signing-in.md) for what happens on their first sign-in.
{% endstep %}
{% endstepper %}

## Getting the timing right

Raise the request **before** the person starts — several days, ideally. Approval and account creation both take time, and setting up their accounts in each system takes more.

Set the start date accurately rather than back-dating to today. Some access is granted based on that date, and a start date in the past can produce odd results.

{% hint style="warning" %}
Check whether the person already exists before creating them. Rejoining employees and contractors converting to permanent staff frequently already have a record. Creating a second one gives them two identities, two sets of access, and a cleanup job for someone later. Search the [directory](/end-user-guide-for-selfservice/directory-lookup.md) first.
{% endhint %}

## If the account isn't created

* **Check it was approved** — see [Request history](/end-user-guide-for-selfservice/requests/request-history.md).
* **Check the start date** — a future-dated request is processed on that date.
* **Give provisioning a little time** after approval.
* **Check the email address** if they say nothing arrived — and check their spam folder.

If the request was approved, the date has passed, and there's still no account, 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/for-managers/new-user.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.