Roles and permissions
The office role catalog, what each role can do, and how access is controlled.
Access to the office console is governed by role-based permissions. Every action in the console — viewing a crew record, editing a vessel, approving a hire — is checked against the signed-in user's roles before it is allowed. This page describes the role catalog and the principle behind it; the underlying enforcement happens on every request, not just in what the interface shows.
Principle: least privilege by default
Access is denied unless explicitly granted. A new user, or a user with no role assigned, can do nothing beyond signing in. Every capability — reading a crew record, creating a job opening, approving an application — is granted deliberately through a role, never assumed by default.
A person can hold more than one role at once, which is the intended way to model someone who genuinely covers two functions — their effective permissions are the union of everything their roles grant.
The office role catalog
SeaSquad CMS ships with a fixed set of system roles for office staff. These cover the day-to-day running of a crewing department:
| Role | Who holds it | What it broadly covers |
|---|---|---|
| Administrator | A small number of people responsible for system configuration | Full authority everywhere, including user and rights management |
| Director | Senior leadership | Final-approval authority in recruitment and promotion, plus broad read access |
| Manager | Departmental managers (deck, engine, fleet personnel) | Approval authority in recruitment and crew management, and oversight of their area |
| Executive | Day-to-day office and data-entry staff, including recruitment | The broadest day-to-day working access — crew records, documents, applications, job openings |
There is also a platform-level operator role used to administer the system itself; it is not assignable to client staff.
What each role can generally do
Access is defined per data area (crew records, documents, vessels, manning, applications, job openings, contracts, reports, and so on) and per action (view, create, update, delete, approve, export). In broad terms, Directors and Managers hold wide read access with update and approval rights concentrated in recruitment, manning, and crew oversight — reflecting a sign-off role rather than day-to-day entry. Executives hold the broadest create/update rights for day-to-day work, but not record-deletion or system-configuration rights: the crew register is a system of record, and even Executives cannot delete a crew record outright.
Role names describe capability, not seniority alone — a Manager and a Director can have overlapping access today, with the distinction showing up in which approvals route to which role rather than in the permission list itself. Where a decision needs a specific person's sign-off (for example, a final approval), that is enforced by the workflow the decision moves through, not by the permission system alone.
Seafarers and applicants are not office roles
Seafarers and job applicants do not hold office roles and are not part of this permission matrix. Their access is governed by ownership, not permission: a seafarer signed into the self-service portal can only ever see their own record, and a job applicant can only ever see their own applications. No configuration grants either population visibility into another person's data, or into office-only information.
How access is enforced
Every non-public action in the office console is checked against the signed-in user's permissions on the server. The interface reflecting what a user can do — hiding actions they lack, showing a clear "no access" message rather than an empty screen — is a convenience, not the actual boundary. The real check happens on every request, independent of what the interface displays.