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

# Requesting and approving app access

> HR requests app access for an employee from a catalogue of reviewed roles; IT/Security approves and provisions it. Nothing is granted until IT approves — and access is provisioned the moment the employee has a login.

Hiring someone in HR records *who they are and how they're employed*. It does **not**, on its own, let them operate one of your business apps. **App access** is the bridge: it turns an employee into an operator of a product — a **SACCO360 Teller**, an **Agri360 Farm Manager**, a **Law360 Associate**, and so on.

Access is a two-party decision. **HR requests** the access an employee needs; **IT/Security reviews and approves** it. HR never grants a product role directly, and IT owns the catalogue of what is even requestable. This keeps a clear record of *who asked*, *who approved*, and *why*.

The flow is the **same for every vertical** — SACCO360, Agri360, Law360, Faith360, Health360, Retail360 and the rest all work through it.

***

## The short version

1. **IT/Security** publishes a catalogue of **access profiles** — reviewed, named roles that HR is allowed to request (a "SACCO Teller" profile, an "Agri360 Farm Manager" profile, and so on).
2. **HR** requests a profile for an employee — from the employee's profile, or while creating them. This grants nothing; it files a request.
3. **IT/Security** sees the request in the **Access** queue and **approves** (or rejects) it.
4. Once approved, the access is **provisioned automatically** as soon as the employee has a login. If they already have one, it's provisioned immediately.

> **Why a catalogue instead of "just pick a role"?** The full list of system roles is large and includes roles that should never be handed to an employee. IT curates a short, business-appropriate menu — and attaches a risk level to each — so HR requests from a reviewed list rather than the raw role catalogue.

***

## For HR — requesting access

**You'll find this on any [employee profile](/hr/user/employees/employee-profile)** (`/hr/employees/:id`), in the **App access** panel on the Overview tab. You can also request access while [creating an employee](/hr/user/employees/create-employee).

### From an employee's profile

1. Open the employee in **HR → Employees**.
2. On the **Overview** tab, find the **App access** panel. It lists any access the employee has already been granted or requested, with its status.
3. Click **Request access**.
4. Pick an **access profile** from the list — e.g. *SACCO Teller*, *Loan Officer*, *Farm Manager*. Only profiles for apps this business runs appear.
5. Click **Request access** to submit.

The request is filed and shows as **Waiting for IT approval**. Nothing has been granted yet.

> 📷 *Screenshot: The App access panel on the employee Overview tab, with the Request access dialog open and a profile selected — to be added.*

### While creating an employee

The [Add Employee](/hr/user/employees/create-employee) form has an **Access requested** card. Tick *"This employee needs to log in and use an app,"* pick a profile, and finish creating the employee — the request is filed automatically **after the employment record is created**. The card states plainly that access is **not granted on save**; IT/Security reviews it first.

> The request is only filed once the employment record saves. Access is an attribute of employment, so an employee with no contract in this business can't be requested for access — if the employment step fails, you'll see *"Employment must be completed before access can be requested."*

### What the statuses mean

The panel shows one of these, and only these:

| Status                           | Meaning                                                                                           |
| -------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Waiting for IT approval**      | Filed. IT/Security hasn't decided yet.                                                            |
| **Approved — waiting for login** | Approved, but the employee has no login yet. It provisions automatically the moment they get one. |
| **Provisioned**                  | Granted and live. The employee can sign in and use the app.                                       |
| **Rejected**                     | IT/Security declined it, with a reason. You can request again (a different profile, or later).    |
| **Failed — retry**               | Approved, but provisioning hit a snag. IT can retry it from the queue.                            |

HR can **request** and **see status**. HR cannot approve, reject or revoke — those are IT/Security decisions and the controls don't appear on the HR side at all.

***

## For IT / Security — approving and managing access

Everything IT does lives under **Settings → User Management → Access**. It has two views: **Requests** (the queue) and **Profiles** (the catalogue).

### The Requests queue

* **Pending** shows requests **Waiting for IT approval**. **History** shows everything decided — approved, provisioned, rejected, revoked, failed, cancelled.
* For each pending request you can:
  * **Approve** — snapshots the role and provisions it (immediately if the employee has a login; otherwise it waits for one).
  * **Reject** — a **reason is required**; it's shown back to HR.
* For access already granted, from History you can:
  * **Revoke** — removes the access. The employee's login is not deleted, and access to *other* products is untouched.
  * **Retry** / **Cancel** — a request that **Failed** can be retried, or cancelled to free the slot.

> An employee holds **one active access request per business** at a time. Approve or resolve the current one before a new one can be filed for that business.

> 📷 *Screenshot: The Access → Requests queue with a pending request and the Approve / Reject actions — to be added.*

### The Profiles catalogue

A profile is one entry HR can request: a **name**, the **app** and **role** it maps to, and a **risk level**. The catalogue starts **empty** — nothing is requestable until you add profiles.

* **Create** a profile: give it a name, pick the app and the role, set the risk level. (The catalogue is honest about being empty until you populate it — that's expected on a new tenant.)
* **Edit**: you can always change a profile's **name**, **description** and whether it's **active**. Once a profile has been **used by a request**, its **app, role and risk level lock** — history renders what was actually granted, so a profile's identity must not drift underneath it. Deactivate it and create a new one instead.

> 📷 *Screenshot: The Access → Profiles catalogue with the New profile form — to be added.*

### Break-glass — granting directly

For an emergency where the normal request-then-approve path is too slow, an administrator can grant access directly from an employee profile's **App access** button in the header. It still selects a **profile** (never a raw role) and **requires a written justification**. The grant is applied immediately and recorded in the Access **History** as a break-glass grant, with your name and the reason — it is never hidden.

***

## Does it behave the same for every vertical?

**Yes — the request-and-approve flow is identical** whatever the product. There's one difference under the hood, invisible to you:

* **SACCO360** is a separate application, so a provisioned grant also sets the person up on the SACCO side automatically. A fresh SACCO operator starts with **no home branch assigned** — they can work right away, and a SACCO administrator can set the branch later.
* **The in-platform verticals** (Agri360, Law360, Faith360, Health360, Retail360, …) are complete the instant the request is provisioned.

***

## Who can do what

| Role                              |   Can request   | Can approve / reject / revoke | Owns the catalogue |
| --------------------------------- | :-------------: | :---------------------------: | :----------------: |
| **HR** (holds *Manage employees*) |        ✅        |               —               |          —         |
| **IT / Security** (Admin)         | via break-glass |               ✅               |          ✅         |

The HR **App access** panel and its **Request access** action appear for HR users who can manage employees. The **Access** tab, the approval controls and the break-glass button are administrator-only.

***

## What happens when someone leaves

When an employee's contract in a business ends, their access **for that business** is revoked automatically — pending requests are cancelled and provisioned access is removed. Access they hold in **other** businesses (for someone who works across more than one) is left untouched.

***

## Related

* [The employee profile & its tabs](/hr/user/employees/employee-profile) — where the App access panel lives.
* [Adding an employee](/hr/user/employees/create-employee) — request access as part of creating the person.
* [The employee directory](/hr/user/employees/employees) — find the employee to open their profile.