Skip to content
SkyRosterBook a working session

Trust · Access control

A permission is two numbers, not one flag

Most systems answer 'can this person see this' with a single yes or no per screen. SkyRoster answers it with a read scope and a write scope, set independently, for each of sixteen areas of the product. What follows is how that actually works, not a marketing description of 'granular permissions'.

Sixteen areas, not one admin switch

Every business area is its own permission

A role is a named bundle of permissions, and a permission is scoped to one specific area of the product rather than to the application as a whole. These are the sixteen:

Organisation settingsRoster managementBaseline requestsBaseline managementLeave requestsLeave managementResource managementTactical planningAttendance managementCompetency managementCompetency matrixShift managementSector managementLocked intervalsReportsDashboard information

A seventeenth marker, none, exists alongside them: setting a role's permission for an area to none switches that area off for anyone holding only that role, rather than defaulting to some minimal read access. Splitting requests from management, and the competency matrix from competency management, is deliberate: it lets an organisation grant someone the authority to approve a leave request without also granting them the authority to redefine the leave policy, or to see the whole organisation's qualification matrix without being able to edit a single qualification in it.

Within several of these areas the model goes one level finer still: leave requests, for example, separates create, delete, send-reminder and cancel into independent actions, and baseline (work, off, swap) requests separates approve and decline from the act of creating one. An organisation can grant a team manager the authority to approve a swap without granting them the authority to delete a leave request.

Try it

The permission model, as a matrix you can interrogate

Read and write are independent axes. Try granting write above read and watch the system clamp it.

The security model, interrogated

verified

SkyRoster gates every business action behind a resource and scopes it with a read level and a write level, set independently, drawn from the same six-tier ladder. The table below lists every one of the16 securable areas the platform recognises. Try pushing a write scope past its row's read scope: with scripting on, it snaps back; the note underneath explains why the backend enforces this regardless.

  • Securable areas

    16

  • Scope tiers

    6

  • Read / write axes

    Independent

  • Write may exceed read

    Never

Compiled from the product source on 12 September 2026 · SkyRoster backend, common-security module, verified against the product source

The permission matrix

Every area gets its own Read row and Write row. Pick a column on either row to set that area's scope for that axis, the two rows are completely independent, which is how a role can see broadly but edit narrowly, never the reverse.

16securable areas, each with an independent read scope and write scope from the6-tier membership ladder.
Securable areaNoneIndividualSelfless PUPrimary unitSelfless mem.MembershipGlobal
Organization settings
Read
Write
Dashboard management info
Read
Write
Competency management
Read
Write
Competency matrix
Read
Write
Shift management
Read
Write
Roster management
Read
Write
Sector management
Read
Write
Tactical planning
Read
Write
Reports
Read
Write
Resource management
Read
Write
Leave requests
Read
Write
Leave management
Read
Write
Baseline requests
Read
Write
Baseline management
Read
Write
Locked intervals
Read
Write
Attendance management
Read
Write

No access
No access at all.
Individual
Only the user's own record.
Selfless primary unit
Primary-unit scope, excluding the user's own record.
Primary unit
The user's own primary organisational unit.
Selfless membership
All units the user is a member of, excluding their own record.
Membership
All units the user is a member of.
Global
The entire organisation.

Why "selfless" scopes exist

modelled

Two tiers on the ladder, Selfless primary unit andSelfless membership · are identical to their plain counterparts except for one subtraction: the user's own record. They exist for approval workflows, so a manager can act on their team's requests without that same permission letting them act on their own.

“Person who ensures the presence at work of the required staff resource. Team Managers usually do not create the roster or manage the staff but do manage their teams schedule and their leave and duty requests.”SkyRoster user manual, ch. 13 Security, §13.3 Security Roles, Team Manager
Team Manager's write scope on Leave Requests approval
  • M. Ionescu Team Manager✓ Eligible to approve · including their own request
  • A. Radu Controller✓ Eligible to approve
  • B. Enache Controller✓ Eligible to approve
  • C. Tudor Controller✓ Eligible to approve
  • M. Ionescu Team Manager✕ Not eligible, it is their own request
  • A. Radu Controller✓ Eligible to approve
  • B. Enache Controller✓ Eligible to approve
  • C. Tudor Controller✓ Eligible to approve

SkyRoster backend, security/roles knowledge base, SELFLESS_MEMBERSHIP / SELFLESS_PRIMARY_UNIT add user.id !== employee.id on top of the base scope

The membership scope ladder

How far a permission reaches

Both the read scope and the write scope of a permission are set to one of the same seven levels, from no access up to the whole organisation:

LevelReaches
NoneNo access at all.
IndividualOnly the user's own record.
Selfless primary unitEveryone in the user's primary unit, excluding the user's own record.
Primary unitThe user's own primary organisational unit, including themself.
Selfless membershipEvery unit the user is a member of, excluding the user's own record.
MembershipEvery unit the user is a member of, including themself.
GlobalThe entire organisation.

The two "selfless" levels exist specifically for approval work. A team manager can be given selfless-primary-unit write access to leave requests: broad enough to approve everyone else's request in their unit, and structurally unable to reach their own record through that same grant. Self-approval is closed off by the scope itself, not by a policy someone has to remember to follow.

Read and write, independently

You cannot edit what you were never allowed to see

Read and write are two separate settings on the same permission, not one flag with an editing side-effect. A role can be given broad read visibility on an area while its write access is scoped much narrower, or shut off entirely.

The reverse combination, write access wider than read access on the same permission, is not merely discouraged: the system clamps write scope down to whatever the read scope is for that role and that area. "Can edit a record but cannot see it" cannot exist as a configuration, because the platform will not save one.

verified

Temporary roles

Delegated access with its own end date

Alongside a permanent role assignment, a user can hold a temporary role with an explicit start and end date, useful for covering a supervisor's leave, a short secondment, or a project that needs a wider grant for a fixed period. The window is evaluated live, to the day, every time permissions are computed; there is no manual step to revoke it, the grant simply stops applying the day after it ends.

When a user holds more than one role that touches the same area, whether both are permanent, both temporary, or one of each, the effective permission is a blend: the widest read scope across those roles, the widest write scope, and visibility if any one of the roles grants it. A temporary role stacks on top of a standing one; it does not have to replace it, and combining two partial roles can grant broader access than either alone. Worth knowing before you assume a temporary grant is purely additive within a single, narrow slice.

Starting points, not a ceiling

Five built-in roles, and unlimited custom ones

SkyRoster ships with five role archetypes that already match how ANSPs and other 24/7 operations are actually organised, quoted here directly from the product's own user manual:

User

“Should be able to use the leave management module to track and request for their leaves and duties. Should also be able to view most of the information that is referring to them such as employee information, competencies validity if in use etc.”

Membership user

“A rostered user should also be able to see their team roster (tactical and pre-tactical). Depending on the preferences, swaps can be allowed, either between teammates or cross teams.”

Team manager

“Person who ensures the presence at work of the required staff resource. Team Managers usually do not create the roster or manage the staff but do manage their teams schedule and their leave and duty requests.”

Head of unit

“Person who is usually responsible with all the exceptional approvals needed in their team. Responsible for the creation of the roster within a department, this person will also have a closer look at the qualification validity and manage it.”

Organisation admin

“Person in charge with managing the staff, responsible for the user data within the platform and also concerned with extracting certain reports that needs to be used in the payroll process.”

SkyRoster user manual, ch. 13, Security roles

These five are a starting point, not a ceiling. An administrator can create an unlimited number of custom roles, each independently configuring read and write access across all sixteen areas, and assign any user one or more roles, permanent or temporary, in whatever combination their organisation's actual authority structure requires.

configured

Where this is enforced

Not just a setting screen

Everything on this page describes what a permission can be configured to say. Whether it is actually respected, at the endpoint, in the command or query handler, and in the database query itself, rather than only in which menu items render, is covered on the security page.

Read next

The rest of the trust section

Bring us a month that went wrong.

A working session is 45 minutes with your own roster on screen, not a canned demo. Bring a pattern that fought you and we will walk through what the engine would have done with it.