> 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/bulk-upload.md).

# Bulk upload

Create or update many people at once from a file, and read the results.

**Bulk Upload** creates or updates many people from a single file — a new intake of starters, a batch of contractors, a set of records that need the same correction.

Open it from **Administration → Bulk Upload**.

## Preparing the file

The file is normally a spreadsheet saved as CSV, with one person per row and one column per field.

Your organization defines the exact columns, so get a template or an example from your help desk rather than guessing at the layout. A file with the right data in the wrong columns fails in confusing ways.

Before you upload:

* **Check for duplicates** — both within the file and against people who already exist
* **Check the email addresses** — one typo means one person who can't sign in
* **Check dates are in the expected format** — the most common cause of rejected rows
* **Start small.** Upload two or three rows first and confirm the result before running two hundred

## Uploading

{% stepper %}
{% step %}
**Select your file and upload it.**
{% endstep %}

{% step %}
**Watch the progress.**

You see a running count:

> *"Synchronization details: Processed … of … Successful: … Failed: …"*

Larger files take longer. The counts update as it works.
{% endstep %}

{% step %}
**Read the synchronization report.**

When it finishes, the **Synchronization Report** lists what succeeded and what failed, with a reason for each failure.
{% endstep %}

{% step %}
**Fix the failures and re-upload just those rows.**

Don't re-upload the whole file — the successful rows have already been processed.
{% endstep %}
{% endstepper %}

## Reading the results

A partial success is the normal outcome on a first run: some rows go through, some don't.

Common reasons rows fail:

| Reason                                | Fix                                                   |
| ------------------------------------- | ----------------------------------------------------- |
| Missing required field                | Fill it in                                            |
| Duplicate — the person already exists | Remove the row, or update the existing record instead |
| Invalid date format                   | Match the format your organization expects            |
| Invalid email address                 | Correct the typo                                      |
| Unknown department, title, or manager | The value must match something that already exists    |

{% hint style="warning" %}
Bulk upload does exactly what the file says, to as many people as the file contains. A wrong value in one column applies it to everybody. Always test with a few rows first — recovering from a bad bulk run is far more work than checking beforehand.
{% endhint %}

## Contractor bulk operations

Where contractors are managed as a group, **Contractor Bulk Operations** offers actions for several at once — **Activate Contractor Operations**, **Deactivate Contractor Operations**, **Initiate Bulk Request**, **Cancel Bulk Request**.

Select the operation, select the people, review the summary, and confirm. Afterwards you see how much succeeded:

> *"… of … request(s) processed successfully"*

The **Contractor Bulk Operations Summary** shows the detail per person, including anything that didn't go through.

{% hint style="info" %}
If you leave the search filters empty, you are warned: *"Search parameters are empty. Select the checkbox above to include all users."* That warning exists because selecting everybody is rarely what you meant — read it rather than clicking past it.
{% endhint %}


---

# 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/bulk-upload.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.