> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to manage access requests and provisioning
- URL: https://blog.jestor.com/manage-access-requests-and-provisioning/
- Published: 2026-09-16T18:53:19.000Z
- Updated: 2026-09-16T18:53:19.000Z
- Author: Bruno Bannach

To **manage access requests** properly, granting and removing access both have to be processes with a record. In **Jestor**, an access request carries the system, the role and the approver, and the same structure handles removal when someone leaves, which is the half most companies skip.

## Why removal is where the risk sits

Joining is visible. Someone cannot work, so the request gets made and chased. Leaving is invisible: nobody is blocked by an account that still exists.

That asymmetry is why most companies have active accounts belonging to people who left, and no list of what anyone actually has.

What a structured process fixes:

- Access granted informally with no record
- Accounts remaining active after someone leaves
- No inventory of who has access to what
- Permissions copied from a colleague without review
- Nothing to show an auditor about access control

## What each request should capture

| Field             | Why                                 |
| ----------------- | ----------------------------------- |
| Person            | Who the access is for               |
| System            | What they need access to            |
| Role or level     | Avoids granting more than needed    |
| Justification     | Required for review later           |
| Approver          | Establishes authorization           |
| Expected end date | Temporary access expires on its own |

## Step by step to structure it

1. **Create a systems registry**, one record per system with its owner.
2. **Build the access request form**, connected to people and systems.
3. **Require justification**, since it is what makes a later review possible.
4. **Route approval to the system owner**, not to a central queue.
5. **Record the grant** with who performed it and when.
6. **Add an offboarding checklist** generated automatically on departure.
7. **Review quarterly**, comparing granted access against current roles.

## Why an end date on temporary access solves most of the problem

Access granted for a project, a contractor or a cover period is the category most likely to be forgotten. Requiring an expected end date, and letting it trigger a review, removes that category without depending on anyone remembering.

## Why choose Jestor

In **Jestor**, access requests are a process with approval routing and a permanent record, offboarding can be a checklist generated automatically, and the platform's own permissions are granular per role, field and action. The history view identifies whether a change came from a person, an automation or the **API**, which is what an access review needs.

## Frequently Asked Questions

### Who should approve an access request?

The owner of the system being requested, rather than a central queue. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### How do I stop old accounts staying active?

Generate an offboarding checklist automatically and require an end date on temporary access.

### Why require a justification?

Because a periodic access review is impossible without knowing why access was granted.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.