# Resource requests

1. [Home](https://www.agilicus.com/)
2. [Agilicus AnyX Administrative Web Interface](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/)
3. [Access](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/)
4. Resource requests

![](https://www.agilicus.com/www/cd0f6037-featured-anyx-admin-accessresource-requests.png)## Resource requests

[CONTACT](/contact-us/)

The **Resource Access Requests** page (route `/resource-access-requests`) lists the requests users have made for access to resources, and is where you approve or deny them.

![Resource requests overview](https://www.agilicus.com/www/f0fbb994-resource-requests-overview.png)    ## Purpose

Users can self-request access to resources that they do not yet have. Each request appears here for an administrator to grant or deny. This page shows every user with outstanding requests, the number of requests each has, and the details of each one: which resource, which role, the reason given, and when it was made.

## Why use it

- Let people ask for the access they need instead of sending you messages.
- Review the reason for each request before granting it.
- Approve or deny in bulk, or grant access for a limited period of 30 days.
- Reply to the user with a message as part of the decision.

## When to use it

- When the request flow is enabled for your organisation (see [Policies and permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/policies-and-permissions/) and [Application request access](https://www.agilicus.com/product-guide/application-request-access)).
- When a user asks for access in the Profile interface and the request reaches the portal.
- During onboarding or role changes, to review what users are asking for.

**Prerequisite**: permission to approve requests (an owner or administrator role).

## How to use it

1. Open **Access > Resource Requests** from the left navigation.
2. Review the list. Each row is a user with outstanding requests, showing their email, first and last name, external identifier, and the number of requests.

![Resource requests overview](https://www.agilicus.com/www/f0fbb994-resource-requests-overview.png)    1. Expand a user's row (select the chevron) to see the requests in detail. The nested table shows the **Resource Name**, **Role**, **Reason**, **Time**, and a per-request **Message** field.

![Expanded user requests](https://www.agilicus.com/www/99076cb5-resource-requests-expanded.png)    1. Tick the requests you want to act on, then choose an action:

- **APPROVE REQUESTS** grants the selected requests.
- **REJECT REQUESTS** denies the selected requests.
- **APPROVE REQUEST FOR 30 DAYS** grants the selected requests with a 30-day limit.

1. If you need to tell the user something, type into the **Enter message to user here...** field; the message accompanies the decision.

### Approval requirements

When you approve requests that include application requests, the portal checks that each one has a valid role assigned. If a role is missing, a dialog explains that approval requires assigning a role to all application requests.

![Approval requires a role dialog](https://www.agilicus.com/www/a6f0e096-resource-requests-approve-dialog.png)    Select **Close** and assign a role (see [Application permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)) before approving, or approve the requests that already have roles.

## Fields and controls reference

| Control | Purpose | Required | Default | Valid values | Notes |
|---|---|---|---|---|---|
| Email | The requesting user's email | Read-only | n/a | n/a |  |
| First name, Last name | The requesting user's name | Read-only | n/a | n/a |  |
| External id | The user's identifier from an identity provider | Read-only | n/a | n/a |  |
| Number of requests | How many outstanding requests the user has | Read-only | n/a | n/a | Expand to see them |
| Resource Name | The resource being requested | Read-only | n/a | n/a | Nested row |
| Role | The role requested on the resource | Read-only | n/a | n/a |  |
| Reason | The user's stated reason | Read-only | n/a | n/a |  |
| Time | When the request was made | Read-only | n/a | n/a |  |
| Message | A note to the user | No | n/a | Any text | Sent with the decision |
| APPROVE USERS | Approves all selected users' requests | n/a | n/a | n/a | Toolbar action |
| APPROVE REQUESTS | Approves the selected requests | n/a | n/a | n/a |  |
| REJECT REQUESTS | Denies the selected requests | n/a | n/a | n/a |  |
| APPROVE REQUEST FOR 30 DAYS | Approves for a limited period | n/a | n/a | n/a |  |

## Dialogs and popups

- **Approval requires a role dialog**: shown when an approval includes application requests without a valid role. It explains the requirement and offers **Close**.
- **Confirmation dialogs**: approving or rejecting requests confirms before acting.

## Configuration versus diagnostics versus confirmation

- **Configuration**: enabling the request flow itself is configured elsewhere (see [Policies](/anyx-guide/agilicus-anyx-administrative-web-interface/access/policies/) and [Application request access](https://www.agilicus.com/product-guide/application-request-access)).
- **Diagnostics**: the request list is the current state of pending requests.
- **Confirmation**: approving grants real access; rejecting denies it and notifies the user. Both are recorded in the audit trail, so confirm the requests before acting.

## Pagination and async behaviour

- The table pages at **25 rows per page**.
- Decisions apply asynchronously. After approving or rejecting, wait a few seconds and reload to confirm the request has left the list. The user is notified of the outcome.

## Troubleshooting

- **No requests appear**: either nobody has requested access, or the request flow is not enabled for the resources in question. Enable it per policy or resource before users can request.
- **Approval is blocked**: the dialog explains that application requests need a valid role. Assign roles to the application (see [Application permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)) and try again.
- **A request references a deleted resource**: the resource name is shown as *DELETED RESOURCE(...)*; such requests cannot be granted meaningfully and should be rejected.

## See also

- [Policies and permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/policies-and-permissions/)
- [Application permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)
- [Resource permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-permissions/)
- [Policies](/anyx-guide/agilicus-anyx-administrative-web-interface/access/policies/)
- [Audits](/anyx-guide/agilicus-anyx-administrative-web-interface/access/audits/)

## Web guide

- [Application request access](https://www.agilicus.com/product-guide/application-request-access)
- [How do I allow users to request access to a share?](https://www.agilicus.com/how-do-i-allow-users-to-request-for-access-to-a-share)
- [Automatic share access](https://www.agilicus.com/automatic-share-access)