Skip to content
SkyRosterBook a working session

Platform · Configuration

Configured per organisation. Not customised per organisation.

Every organisation that runs SkyRoster runs the same product. What differs is a set of screens an administrator, not a developer, fills in: which shift types exist, how a swap gets approved, how heavily a rule is weighed, what a week starts on, who can see what. That distinction is not a technicality. It is the difference between a rule change taking an afternoon and a rule change taking a change request to us.

The argument

Why this is the differentiator, not a footnote

Customised means forked

A customised product diverges from every other customer's copy the day someone edits it for you. Every later fix, every later feature, now has to be reconciled against that fork, or it never reaches you at all. Your collective agreement becomes our maintenance burden.

Configured means a setting

A configured product is one product with a settings layer. Your rule thresholds, your approval chains, your holiday calendars live in your own instance's data, not in a branch of the source code. A fix or a new capability reaches every organisation, including yours, without anyone having to re-apply your changes on top of it first.

Concretely: 102 of the 133 scheduling rules the engine can enforce are administrator-tunable, enabled or disabled, weighted, and set as a hard stop or a soft preference, from a settings screen. The remaining rules are the data-integrity guards no organisation would want to turn off, an assignment cannot exist twice, history cannot be silently rewritten, so those stay fixed.verified See the full rule catalogue.

Shift types and patterns

The building blocks a unit defines once

Shift types

A named definition, Morning, Afternoon, Night, on-call, carrying its working, night, off or flexible classification, its display time window, the minimum rest it requires afterward, a colour for the roster grid, and its own per-request-type approval setting. Change one and every roster built against it reads the change; nothing is hard-coded per customer.

Shift patterns and demand

A reusable rotation, such as a four-on, four-off sequence, or a per-shift-type headcount requirement that can vary by day of the week, is configured once and reused across rosters rather than rebuilt each month. The full mechanism, including flexible shifts and manpower requirements, is on the strategic rostering page.

Request types and approval chains

6 request types, one approval engine, your own chain per type

Leave, duty, work requests, off requests, shift extensions and swaps all share one generic approval engine: an ordered list of steps, each naming who is eligible to act on it. What differs by organisation is how many steps there are, who they name, and whether a step requires the person's own consent, and all of that is a setting, not a code branch.

Request typeWhere the approval chain is configured
LeavePer leave type, two chains (operational / non-operational)
DutyPer duty type, same two-chain mechanism as leave
Work requestPer organisational unit
Off requestPer organisational unit, same chain as work requests
Shift extensionPer organisational unit
SwapPer organisational unit, plus 0 or 2 individual-consent steps

Each step names one or more eligible-approver mappings, a membership scope paired with a role, and a step is satisfied the moment anyone matching any of them acts. At most one step per chain may be a Primary Head of Unit mapping. The full approval-engine mechanics, including live eligible-approver computation, are on leave and duty and shift swaps.

Rule thresholds and weights

A number your unit set, not a number we picked

Behind almost every rule sits the same record: whether it is switched on, how heavily it is weighed, what its numeric threshold is, over what period, and whether it is a hard stop or a soft preference. Two named examples outside the core rule catalogue show the same idea applied to fairness and to tactical staffing:

Vacation Score tables

An admin defines a biweekly calendar of scored periods, so a request for a popular week in August can be weighed against one for a quiet week in February when two people want the same dates. Different employee populations can run different tables, and an employee's earned score can only ever go up, never be eroded by a later correction.configured

Tactical threshold limits

Demanding a hundred per cent of every staffing requirement is sometimes not operationally possible during a genuine shortage. A threshold table sets the shortfall your unit will tolerate, as a percentage or a headcount, tracked separately for day and night, because night operations often run leaner by design. See tactical rostering.

This is also the mechanism behind the honesty on how the engine decides: whether minimum rest time is a hard, non-negotiable stop or a heavily weighted preference is your unit's decision, encoded here, not a difference in code between customers.

Time, week and holiday settings

The calendar the whole roster is built against

Time settings

Hours per working day, and the start and end of the night-shift window that feeds night-differential pay and rest-rule logic. Tenant-wide, and audited field by field.

Week settings

Which day starts the week, and which days count as working days for the whole organisation, so a report or a roster grid lines up with how your unit actually counts a week.

Holiday calendars

Assigned per unit, and a multi-country organisation can run several at once. The full mechanism, including bridge days, is on staff records.

Permissions

16 securable areas, a 6-level scope on each

Access is not one admin switch. Every securable area of the product carries an independent read scope and write scope, each set on the same ladder from an employee's own record up to the whole organisation, and a write grant can never exceed its own read scope. Five built-in roles cover the common ANSP job functions out of the box; an administrator can define as many custom roles as the organisation needs, and can grant one person a temporary role for a fixed date window to cover a secondment or an absence.

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

Translations

2 interface languages, and localisation deeper than labels

SkyRoster's interface is available in English and Portuguese.verified

Localisation goes past static labels: notification titles, month names in date displays and the plain-language explanation of a rule violation are all generated in the interface's own language, and the layout itself is built to survive a language whose text runs systematically longer than English. Additional languages are a configuration and translation exercise, not a rebuild. Only English and Portuguese are shipped and verified today, said plainly rather than implied broader.

How it scales

Set it once at the top, override only where you mean to

What makes all of the above practical for an organisation with dozens of units rather than one is inheritance. A unit's contract, its leave allowance, its request caps, its overtime ceiling, cascades automatically to every sub-unit and employee beneath it. Change the top-level setting once and the change ripples down on its own. A unit or an employee can be shielded from that cascade with an explicit “read-only” flag, or given its own custom terms, so a national default and one senior team's richer overtime allowance can both be true at once, deliberately, not by accident.

The engine

How the engine decides

Rule settings are the input. This is what the solver does with them: construction, local search, hard, soft and the weights in between.

Bring your own rulebook.

A working session maps your actual approval chains, rule thresholds and roles onto these settings screens, so you see your organisation's own configuration, not a demo tenant's.