| Sequence | Primary owner | Also touches | Feeds into |
|---|---|---|---|
| The roster month | Roster officer | Head of unit, on a Major publish | The operational day's demand baseline |
| The operational day | Head of unit or supervisor | Controllers, on their own phone, read-only | This month's attendance record |
| A request, end to end | The requester and whoever is eligible to approve, computed live | Roster officer (the roster changes), payroll (balances move) | Both the live roster and the payroll pipeline |
| Month end | HR and payroll officer | IT and security, on every settings change | The file your own payroll system ingests |
Lifecycles
The same system, told as a timeline four times, because that is how it is actually used
Nobody at an ANSP experiences SkyRoster as a list of ten modules. A roster officer experiences a month getting built. A head of unit experiences a day getting run. An employee experiences one request moving from a tap on a phone to a changed schedule. A payroll officer experiences a month closing. These four sequences are how this site describes the product instead: each one a short walk through what actually happens, in order, with who is holding the decision at each step.
Weeks before · once a cycle
The roster month
A manpower requirement becomes a draft, a draft becomes a solve, a solve becomes a baseline someone signs their name to.
Hour by hour · every day
The operational day
The published baseline meets real positions, real sectors, and whatever the shift actually throws at it.
Whenever someone asks
A request, end to end
One swap, or one work request, from a tap on a phone to the coded line it becomes in an export.
Once a cycle · and it's final
Month end
Attendance reconciles, overtime classifies itself, and a payroll officer signs off on a number she can defend.
Ownership
Which person owns each sequence, and who else it reaches
How the handover actually works
None of these four sequences is a silo. Each one writes into the next
A published roster month is not a document that sits still until someone opens the wizard again. Every ongoing operational event, a leave approval, a duty approval, an approved swap, an extra shift, mutates that published baseline directly and re-publishes it automatically. That is the mechanism that lets the operational day and a request's own approval chain change the same roster the roster month produced, without anyone reopening the draft.
A concrete chain
A controller calls in sick at 03:00. A leave request clears through its configured chain. The tactical workbench, polling every five seconds, shows the gap without a refresh. The resulting mandatory-period change is silent because it is still in the future when it happens.
Why the past needs a signature
The same reschedule, made against a period already underway or already elapsed, needs a supervisor's explicit approval, because attendance and payroll figures were already computed against that window. Rewriting it silently would quietly corrupt both.
Where it lands
Every one of those events eventually reaches month end as an attendance entry, a justification, or a coded overtime line, the sequence that has to make the whole month defensible on one signature.
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.
Who else will ask, and what they will want