# Access Profiles and On-boarding Cases
URL: https://docs.autociso.io/release-notes/2026-10-onboarding-access-profiles/
Description: Describe the access each role needs once, start a joiner case with an automatic To-Do list, and read joiner cases over a read-only jml:read API.

## Access Profiles and on-boarding cases

**Plans:** The Seed and above (Employee lifecycle)
**Where:** **Lifecycle (JML)**, tabs **Access Profiles** and **Joiner (Onboarding)**; `/api/v1/jml/onboarding/`
**Versions:** backend 2.6.0, console 2.5.0, docs 0.2.0

New hires used to start with an empty checklist. This release lets you describe the access each role needs once, and turns it into a To-Do list for every joiner that tracks whether the access really arrived.

**Who benefits:** the IT manager who sets up new hires, and the engineer or MSP who wants a joiner feed for a ticketing tool.

### What's new

#### Access Profiles

On the **Access Profiles** tab, click **New access profile**, choose who it applies to (by **Department**, **Job title**, **Employment type**, **Country** or **Office**, or turn on **Applies to every employee**) and select the **Required access**. The list shows how many employees each profile matches, and an **Asset removed** tag when an application in a profile no longer exists.

#### Joiner cases with a To-Do list

On the **Joiner (Onboarding)** tab, click **New joiner**, pick the employee and click **Create joiner**. The matching profiles produce a To-Do list; each item turns **Granted** when AutoCISO sees the access, or **Marked done** when you click **Mark as done** and add a note. Use **Show joiners** to switch between **Open**, **Completed** and **All**, and **Refresh from profiles** to pick up new requirements (new items carry a **New** tag; nothing is removed). **Edit due date** and **Cancel case** are on each joiner, and a joiner past its due date shows **Overdue**. The **Suggest access for a job title** panel proposes applications for a role from what peers already have.

An employee can have only one open joiner case at a time.

#### A read-only on-boarding API

Four endpoints under `/api/v1/jml/onboarding/` return joiner cases and their items: list cases, get one case, list a case's items, and a cross-case item feed for polling. All need `jml:read` and a plan with Employee lifecycle. Name and email in the two **case** endpoints need `pii:read` on the same token; the two **item** endpoints never carry a name or an email, only the employee ID. The [OpenAPI file](https://docs.autociso.io/openapi/public-v1.yaml) is now version 1.1.0.

**Two feeds, two defaults.** `GET /offboarding/items` includes `COMPLETED` cases by default. `GET /onboarding/items` returns only items of `OPEN` and `IN_PROGRESS` cases by default. Use `filter[caseStatus]` on the on-boarding feed to include completed joiners.

#### Console-only changes

Creating and editing profiles and joiners, marking items done, refreshing, changing a due date and cancelling a case go through the console-only management endpoints, which work for signed-in people only. API tokens cannot call them.

#### New error codes in the console

If a console action cannot be completed you may see one of these codes in the response: `CASE_ALREADY_OPEN` (this employee already has an open joiner case), `CASE_NOT_MUTABLE` (the case was completed or cancelled), `EMPLOYEE_NOT_ELIGIBLE` (the employee has left the company), `CONFLICT` (the item or profile was changed by someone else; reload and retry) and `ATTESTATION_NOTE_REQUIRED` (marking an item done needs a note). The console shows a plain-language message for each. The read-only API never returns them.

### How to use it

1. Open **Lifecycle (JML)**, tab **Access Profiles**, and click **New access profile**.
2. Open **Joiner (Onboarding)**, click **New joiner** and **Create joiner**.
3. Follow [Create Access Profiles and start an on-boarding case](https://docs.autociso.io/product/lifecycle/onboarding/). For the API, see the [On-boarding API](https://docs.autociso.io/api/reference/onboarding-cases/list/).

### Rollout

The on-boarding API follows the same per-deployment switch as the off-boarding API. Where it is not enabled, the endpoints answer `403 FORBIDDEN`.