Docs / Get started

Roles and permissions

The nine staff roles, the read-all write-by-module matrix behind them, who may move an application into which stage, and who may override a blocking requirement.

4 min read·Last updated September 3, 2026

The authorization model is three rules: read all, write by module, advance by owning role. Every officer can see every applicant and application, because the entire point of the platform is the handoff between officers. Writing is scoped to the module a role owns. Moving an application forward is limited to the role that owns the stage being entered.

The nine roles#

“Fully” means create, read, update and delete. Where a module is listed without qualification the role has read, create and update but not delete.

What everyone can read#

Regardless of role, every staff member can read these modules. A Liaison Officer chasing a visa can look at the applicant’s screening notes without anyone granting them anything.

• applicant, application, endorsement, interview
• principal, jobOrder, jobBoard
• document, govClearance, liaison, welfare
• accounts, marketing, email, chat, task, report

Notably absent from that list: settings, user, billing, automation and audit. Those are administrator surfaces. report and audit are read-only even for an Owner.

Who can move an application#

Stage advancement is a separate check from module write permission, and both must pass. The rule is:

• An Owner or System Administrator may move an application into any stage.
• Any other staff member may move it only into a stage whose owningRole matches their own role.
• A stage with no owning role is open to any staff member who can write applications.
• Terminal stages are always open. Withdrawals, rejections and disqualifications come from anywhere in the process, so blocking them would strand records.

In practice this is what makes the seeded stage tree a workflow: Medical Examination is owned by the Liaison Officer, Document Processing by the Document Officer, Payment Status by Accounts. A recruitment officer cannot quietly walk an application through another officer’s stage.

One further constraint comes from the transition list itself: from any stage you may move to the immediate next active stage or to a terminal stage. You cannot skip three stages ahead. See Stage gates.

Overriding a blocking requirement#

Only OWNER and SYSTEM_ADMIN may override a blocking stage requirement, and an override is not a click. It needs a written reason of at least ten characters, the reason is stored, and the full set of unmet requirements is snapshotted onto the stage-history row as it was at the moment of the override.

The move is then recorded as application.stage_overridden rather than application.stage_advanced, which means overrides are countable and separable in the audit trail rather than blending into ordinary progress.

The receptionist exception#

A receptionist can create an applicant but cannot update applicants generally. That would make walk-in intake unusable — a typo in a surname would need another officer. So there is one narrow exception: a receptionist may update an applicant record they created themselves. Anyone else’s record stays read-only to them.

Portal users are not in this matrix#

The staff matrix returns false for every non-staff user type. Applicant and employer portals have their own guards and their own payloads; they cannot reach staff modules by any path through this model.

What is not built yet#

The audit trail already reserves the action names user.invited, user.role_changed and user.deactivated for when that arrives. Nothing emits them today.