> 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-access/access-profiles.md).

# Access profiles

Request a ready-made bundle of access that matches a job, instead of asking for items one at a time.

An **access profile** is a pre-packaged bundle of access that suits a particular job — everything a new *Warehouse Supervisor* or *Claims Handler* needs, gathered under one name.

Rather than working out which eight applications and four groups the job requires, you request the profile and get the lot.

You ask for one the same way you ask for anything else — through **Create Request** — see [Requesting access](/end-user-guide-for-selfservice/requests/request-access.md). Whether profiles are offered to you, and under which catalog category, depends on what your organization has published.

{% hint style="warning" %}
**Do not confuse this with the *****Access Profile***** page in the sidebar.** **Access Management → Access Profile** shows the access *you already hold* — see [Your access](/end-user-guide-for-selfservice/your-access.md). It is not a catalogue of profiles you can request, despite the similar name.
{% endhint %}

## Why profiles exist

They solve a problem that shows up whenever someone joins or changes role: nobody remembers the full list.

* **For you** — one request instead of twelve, and nothing forgotten.
* **For your approver** — one decision about a recognisable job, instead of twelve decisions about individual permissions.
* **For your organization** — people in the same job end up with the same access, which makes reviews far easier.

## Using a profile

{% stepper %}
{% step %}
**Start a request and find the profile you need.**

Profiles are usually named after jobs or functions, so look for the role rather than the tools.
{% endstep %}

{% step %}
**Look at what it contains.**

A profile lists the roles, groups, and resources it will grant. Read this before requesting — you are asking for all of it.
{% endstep %}

{% step %}
**Request it.**

The request goes through the normal approval route. See [Requesting access](/end-user-guide-for-selfservice/requests/request-access.md).
{% endstep %}

{% step %}
**Check the result.**

Once approved and granted, the contents appear individually in [Your access](/end-user-guide-for-selfservice/your-access.md).
{% endstep %}
{% endstepper %}

## Things worth knowing

* **A profile is a starting point, not a permanent link.** Once granted, you hold the individual items. If the profile is changed later, your access does not automatically change with it.
* **You may already hold some of it.** Requesting a profile when you have part of it is fine — you are granted the missing pieces.
* **You can still request extras.** A profile covers the common case; anything unusual is a separate request.
* **Approval may be split.** If different people own different parts of the bundle, each part can be approved separately — so a profile can be partly granted while one item is still pending.

{% hint style="info" %}
If you are setting up a new joiner and your organization has a profile for their job, use it. It is faster than assembling the list yourself, and far less likely to miss something they need on day one.
{% 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/your-access/access-profiles.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.