> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Requests

> Let employees request access to applications and groups, route each request through an approval chain, and grant access automatically once it's approved.

Provide just-in-time access to applications for employees. Every request runs through an approval chain that you define, and Oleria grants or revokes the access automatically once a decision is made.

## How access requests work

1. **Admins configure request sources** - as an administrator, you choose which applications and groups employees can request, and assign an [**Approval Chain**](#approval-chains) to each. Alternatively, configure [**Custom Access**](#custom-access).
2. **Employees submit requests** - employees browse the catalog of requestable access and submit a request with a justification.
3. **Approvers get notified** - Oleria notifies approvers by email, Slack, or Microsoft Teams as each step in the chain activates.
4. **Approvers decide** - approvers approve or deny the request, or a step resolves automatically based on the approval method you configured.
5. **Oleria grants or denies access** - once every step in the chain is approved, Oleria provisions the access. A denial at any step stops the chain and denies the request.

### Requesting access

Employees submit and track access requests from the Oleria governance portal at `youroleriainstancename-governance.oleria.io`.

<Steps>
  <Step title="Browse requestable applications">
    From the Governance App, go to **Requests** and select an application (or Custom Access) from the catalog.
  </Step>

  <Step title="Choose a level of access">
    If the application has more than one configured group, select the level of access needed. Oleria shows what percentage of the requester's peer group already holds each level, based on the past 30 days of activity and current access.
  </Step>

  <Step title="Add a business justification">
    Explain how the application will be used. Administrators can require this field.
  </Step>

  <Step title="Set a duration">
    Specify how long the access is needed, if the request source allows a custom duration. If access is configured as permanent, this step is skipped.
  </Step>

  <Step title="Submit the request">
    Select **Request access**. The request moves into the assigned approval chain, and the employee can track its status under **My requests**.
  </Step>
</Steps>

<Note>
  If an employee already has active access to a group and submits a new request for it, the new request extends the existing access instead of granting a separate grant. The original grant is marked superseded once the extension is approved.
</Note>

## Approval chains

An approval chain is a sequence of steps that must be completed in order. When a step is approved, the next step activates automatically. Every step must approve for access to be granted - if any step denies the request, the chain stops immediately and the request is denied.

Each step uses one of the following approval methods:

| Approval method | How it decides                                                                                                                                                                                                                                                |
| :-------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Manual          | One or more approvers must review and approve the request.                                                                                                                                                                                                    |
| Conditional     | Oleria evaluates the request against conditions you define. Requests that match an approval condition are approved automatically; requests that match a human-review condition are routed to approvers. Requests that match neither are denied automatically. |
| Webhook         | An external service you configure receives the request and returns an approve or deny decision.                                                                                                                                                               |
| Always approve  | No approvers are needed - the step approves automatically. You can add a delay before the automatic approval resolves. Always approve can't be combined with other steps - it must be the only step in the chain.                                             |

For manual and conditional steps, approvers can be the requester's manager or a specific list of people you choose. If an approver would be reviewing their own request, Oleria skips them and falls back to the next available approver.

<Note>
  Oleria doesn't allow a request to have no valid approver. If every possible approver resolves back to the requester, the request can't be submitted.
</Note>

### Creating an approval chain

<Steps>
  <Step title="Open approval chains">
    In the admin portal, at youroleriainstancename.oleria.io, go to **Governance** -> **Access Requests** -> **Approval chains**, and select **New chain**.
  </Step>

  <Step title="Name the chain">
    Give the chain a name and, optionally, a description.
  </Step>

  <Step title="Add steps in order">
    Add up to five steps. For each step, choose an approval method and configure it:

    * **Manual** - add approvers by choosing the requester's manager, specific people, or both.
    * **Always approve** - optionally set a delay before the step resolves.
    * **Conditional** - define the conditions that trigger automatic approval and the conditions that route to human approvers.
    * **Webhook** - select the webhook that should receive and decide the request.
  </Step>

  <Step title="Save the chain">
    Select **Save**. Editing a chain later creates a new version - requests already in progress continue on the version they started with.
  </Step>
</Steps>

Once a chain exists, assign it to a requestable application or role from **Governance** -> **Access Requests** -> **Applications**.

## Custom Access

Custom Access lets you make anything requestable, not just directly connected applications - an internal tool, an application not integrated with Oleria, or any action you can trigger with a webhook call. Custom Access items use the same justification, duration, and approval chain options as applications. The difference is how access gets provisioned once a request is approved.

<Steps>
  <Step title="Open Custom Access">
    Go to **Governance** -> **Access Requests** -> **Custom Access**, and select **New custom access**.
  </Step>

  <Step title="Name and describe it">
    Give the item a name and description. Employees see these in the request catalog.
  </Step>

  <Step title="Connect a webhook">
    Select the webhook that provisions this access, and add any parameters that should be sent on every request.
  </Step>

  <Step title="Configure the request form">
    Define the fields employees fill in when they request this access. Fields can be required or optional.
  </Step>

  <Step title="Set duration, expiration, and justification">
    Choose whether access is permanent or time-limited, how long a pending request can stay open before it expires, and whether a business justification is required.
  </Step>

  <Step title="Assign an approval chain">
    Select the approval chain that should govern requests for this item, and choose whether to notify approvers by email or Slack.
  </Step>
</Steps>

<Note>
  Custom Access is provisioned and revoked through the webhook you configure. If the webhook doesn't return a successful response, the request or revocation fails without affecting other pending requests.
</Note>

### Requesting Custom Access

Employees request Custom Access the same way they request application access, from the **Custom Access** tab in the Governance App catalog. The request form shows whatever fields you've configured instead of an application and role, and submissions are tracked separately under **My Custom Access Requests**.

## Reviewing and approving requests

Approvers review and act on requests from **Approvals** in the Governance App, under the **Pending**, **Approved**, and **Denied** tabs.

Selecting a request shows the application, role, requested duration, business justification, and the approval history for the chain so far. Approvers can:

* **Approve** the request.
* **Deny** the request, which requires a reason.

Notifications sent by email, Slack, or Teams include the same **Approve** and **Deny** actions, so approvers can act without opening the Governance App.

### Request statuses

| Status           | Meaning                                                                                                                |
| :--------------- | :--------------------------------------------------------------------------------------------------------------------- |
| Pending approval | The request is in an active step of the approval chain.                                                                |
| Approved         | Every step in the chain approved the request. Provisioning starts next.                                                |
| Denied           | A step in the chain denied the request.                                                                                |
| Provisioning     | Access is being granted, including a Custom Access request waiting on a webhook response.                              |
| Access granted   | Access has been provisioned and is active.                                                                             |
| Failed           | Provisioning or revocation didn't complete - for example, a Custom Access webhook didn't return a successful response. |
| Revoked          | Access was removed, either at the end of its duration or by an administrator.                                          |
| Expired          | A time-bound grant reached the end of its duration and access was removed.                                             |
| Canceled         | The requester withdrew the request before a decision was made.                                                         |
| Superseded       | The request was replaced by a later request that extended the same access.                                             |

### Admin overrides

Administrators can override a request's outcome directly - approving, denying, or revoking access outside the normal chain. Every override requires a reason, and it's recorded in the request's activity history alongside the decisions made by the chain.

<Note>
  Only Oleria Administrators can configure request sources, build approval chains, or override request decisions. [View role permissions](/administration/default-user-roles).
</Note>

## Contact us

For questions, contact us at [support@oleria.com](mailto:support@oleria.com).