> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/admin-user-guide/access-policies-and-approvals/approvals.md).

# Approvals

Approvals sit between a user asking for something and getting it. A user raises a request in the Self Service Portal; an approval configuration in the admin console decides who has to agree before it is granted.

This step covers all of it — how a request is raised, how the approver acts on it, and how you configure who that approver is.

## Raising an access request

Users raise requests themselves. In the Self Service Portal, open **Access Requests**.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/bq6OR3rPoETvYjBe7N9t/assets/01.png)

The **My Requests** tab lists what the user has asked for; **Approvals** lists what they have been asked to decide on.

| Column         | Shows                                                                |
| -------------- | -------------------------------------------------------------------- |
| Request ID     | The request's reference                                              |
| Request Type   | What was asked for — access, or registering an authentication method |
| Priority       | **Low**, **Medium**, **High** or **Critical**                        |
| Requested For  | Who the access is for                                                |
| Requested Date | When it was raised                                                   |
| Status         | Approved, pending, or deleted                                        |
| Action         | View or delete the request                                           |

### Submitting a request

Select **Submit Request**.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/pRtT94VIzf6qb2oHa7SA/assets/02.png)

| Field         | What to enter                                                   |
| ------------- | --------------------------------------------------------------- |
| Request For   | **Myself** or **Others**                                        |
| Request Type  | The kind of request. Required                                   |
| Priority      | Low, Medium, High or Critical. Required                         |
| Resource Type | **Application**, **System** or **Public Application**. Required |
| Description   | The reason for the request, up to 500 characters                |
| Captcha       | Required                                                        |

Choosing a resource type adds the fields it needs — the resource itself, and the roles being asked for.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/qusuXPCru3GnM1groJ75/assets/03.png)

Select **Submit Request**. The request appears in **My Requests** and goes to whoever the approval configuration names.

> **Note** The **Description** is what the approver reads before deciding. A request with a blank description gives them nothing to judge, and tends to sit unapproved.

## Acting on a request

Approvers work in the portal too. A request that names someone as approver lands in the **Approvals** tab of their own **Access Requests** page — they never need an admin console sign-in to deal with it.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/kVsGn1W1x5Sflh7XHtnc/assets/11.png)

**Pending**, **Approved** and **Rejected** split the list, with the number of pending items beside them. Search, **Filters** and **Export** work as they do elsewhere.

### The three actions

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/p3Nui3sOBnBQTmhOCrKr/assets/12.png)

| Icon  | Action                   |
| ----- | ------------------------ |
| Eye   | Open the request in full |
| Tick  | Approve it               |
| Cross | Reject it                |

### Viewing a request

The eye icon opens **Request Details**.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/lNhevy2vsZBCxlKMXWfS/assets/13.png)

The header carries who asked, who it is for, the request type and date, the application and the role being requested, the category, the status, the priority and the requester's description. Three tabs sit below it.

| Tab                                 | Shows                                                                                           |
| ----------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Access to Requested Application** | Who already has access to this application, by user and by group, with the role and access type |
| **Access to Other Applications**    | What else the requester can already reach                                                       |
| **Approval History**                | What has happened to this request so far                                                        |

The middle tab is the one worth opening before you decide. A request for Admin on one application reads differently once you can see the person already holds Admin on four others.

### Approving

The tick opens **Approve Access Request** — the same detail, with the access it involves listed underneath.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/g3TIeooKp9YUwdVf4XfO/assets/14.png)

Review it and select **Approve**. The access is granted at that point; there is no further step to remember.

### Rejecting

The cross asks for a reason, and will not proceed without one.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/EkWI4i3yJDwOaIyg1nRu/assets/15.png)

Write it for someone who was not in the conversation. The reason goes back to the requester, and it is what gets read again during an access review months later.

## The Approval Workflow Configuration page

In the admin console, open **Approvals**.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/WhJQli9QGl4aEzQo0sNm/assets/04.png)

Four tabs, one for each kind of request:

| Tab                      | Governs                                                                                               |
| ------------------------ | ----------------------------------------------------------------------------------------------------- |
| **Authentication Types** | Registering or updating an authentication method — TOTP, DSC, GRID, KBA, email address, mobile number |
| **Access Request**       | Requests for access to an application, system or public application                                   |
| **Group Request**        | Requests to join a group                                                                              |
| **Profile Updation**     | Changes a user makes to their own profile                                                             |

Each tab lists the configurations already in place: the request type, its primary and alternate approvers, whether approval is required at all, who created and last modified it, and its status.

## Creating an approval configuration

The wizard is the same on all four tabs. Select **Add Configuration**.

### Step 1 — Request details

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/izqpUw9ur94od1lvOqLO/assets/05.png)

| Field                       | What to set                                                                                                        |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Request Type                | Which request this configuration governs. Required — and if a configuration already exists for it, you are told so |
| Reporting Manager Approval? | **Yes** routes to the requester's own manager                                                                      |
| Approval Required?          | **No** means the request is granted without anyone approving it                                                    |
| Primary Approvers           | Who decides. Required when approval levels are used                                                                |
| Alternate Approvers         | Who can decide in their place                                                                                      |
| Fulfilment Window           | How long the approver has to act                                                                                   |
| Escalation Threshold        | How long before the request escalates                                                                              |
| Escalation Notifications    | Email addresses alerted on escalation. The **+** adds more                                                         |

**Add Level** creates a second approval level, so a request passes to the next approver once the first has agreed.

> **Note** Set either **Reporting Manager Approval** or **Approval Levels** — one route or the other. And **Approval Required = No** is a real choice, not an oversight: use it for low-risk request types that should just go through.

### Step 2 — Review approvals

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/dbc0pb4coP6BcSKFdv5g/assets/06.png)

The summary restates what you have configured — request type, whether the reporting manager approves, and whether approval is required at all. Check it, then select **Save**.

## What differs between the four tabs

The form is the same; the request types differ, and Group Request adds one field.

### Access Request

The request type list holds **Access\_Request**.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/sBP8IC2pqJZanhznnNQ2/assets/07.png)

### Group Request

Adds a **Groups** field, so the configuration applies to the groups you name rather than to every group.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/3HToyrgmwRUxpYJm985a/assets/08.png)

### Authentication Types and Profile Updation

Identical to the Access Request form. Only the request types differ — Register TOTP, Register DSC, Register GRID, Register KBA, Update Email Address, Update Mobile Number.

## Managing a configuration

Three actions on each row.

### View

Opens the configuration read-only — request type, resource, whether the reporting manager is required, whether approval is required, status, who created and modified it, then each approval level with its approvers.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/XkgnxzaR4Hfq58MzNGP5/assets/09.png)

### Edit

Reopens the wizard so approvers, windows and thresholds can be changed.

### Delete

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/Gq3SrXEH0w2Gst9vBoth/assets/10.png)

Select **Delete Permanently**.

> **Caution** Deleting a configuration does not block that request type — it removes the approval requirement. Requests of that type will then be granted with nobody approving them. If the intent is to stop the request type, edit the configuration instead.

The portal is where people ask and where approvers decide; the four tabs under Approvals settle who has to say yes in the first place. The setting worth checking twice is **Approval Required** — turning it off is the difference between a governed request and an automatic one.