Custom roles & Access Area

Under Settings → Roles & permissions, admins can create custom roles beyond the built-in system roles (Admin/Employee). Each role is a matrix with one row per feature area and three levels: no access, read, or write. A role still held by any user can’t be deleted — you’re warned about this before you try. Related feature areas render nested under one shared parent row (e.g. Salary Mapping with its sub-areas, or one row per document category actually defined in your organization) — setting the parent row’s level fills in every child row in one step. The exception is a child row that only allows one Access Area, e.g. Annual report & archive (All only) and Report a case (Own only): if the parent’s level or Access Area doesn’t fit, it isn’t inherited — the child is set to no access and shows a note explaining why. Pick a level on the child row itself if the role should have it.

Access Area — WHO the role can see, per feature row. On top of the read/write level, for EACH feature row separately (not once for the whole role) you pick one of four “Access Area” modes controlling which employees’ data that row can see/affect:

Own — only the role holder’s own record, nothing else.
Reporting Line — the role holder plus everyone who reports to them (directly or indirectly) in the org tree. This is resolved fully automatically from whoever is actually signed in — there is nothing to configure or pick a department for; someone with no reports sees only themselves, a manager sees their whole team recursively.
Custom Filter — every employee matching at least one condition you set (e.g. Employment Type = Consultant). Requires at least one condition to be saved.
All — the whole organization, unrestricted, within that feature.

This replaces the old single “department scope” picker: instead of ONE shared department restriction for the whole role, each feature row can now carry its own Access Area mode — a role could have “All” on Surveys but “Reporting Line” on Salary, for example.