Access Profiles and On-boarding Cases
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 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
- Open Lifecycle (JML), tab Access Profiles, and click New access profile.
- Open Joiner (Onboarding), click New joiner and Create joiner.
- Follow Create Access Profiles and start an on-boarding case. For the API, see the On-boarding API.
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.
Was this page helpful?