Skip to content
SkyRosterBook a working session

Lifecycles · A request, end to end

One tap on a phone becomes a changed roster and a payroll line. Here is everything between

SkyRoster supports six self-service request types, leave, duty, work requests, off requests, shift extensions and swaps, and every one of them moves through the same underlying machinery. Rather than list that machinery as features, this page follows two concrete requests, a shift swap and a work request, from the moment someone submits to the moment payroll sees the result.

Stage 1 of 7 · Submit

Two employees, two different problems, the same starting screen

Worked example A · The swap

Two controllers want to trade a shift. From the Team Scheduler, one enables swap mode, taps their own shift, then the colleague's. A team lead browsing the wider crew grid can select across two other people's rows and propose it on their behalf.

Worked example B · The work request

A supervisor needs someone on a rest day to cover a gap (see the operational day). They open that employee's rest-day cell, pick a qualification the day's demand calls for, and place them on it.

Both requests, and the four others alongside them, share one generic approval engine underneath, covered from stage 3 on. Where they differ first is what happens before that engine ever sees them.

Try it

Every check, reported at once

Stage 2 of 7. A swap changes a published roster, so before it can even be submitted it has to pass a dedicated eligibility gate, 24 automated checks, grouped below, that all run and all report at once. A work request has no equivalent: it is governed by the generic approval chain in stage 3 and the balance computation in stage 6, not by a standalone gate like this. Pick a scenario and watch what the swap's gate actually checks.

Try a swap

verified

It doesn't stop at the first broken rule.

Two controllers propose to trade shifts. SkyRoster runs 24 automated checks against the trade: qualifications, rest, overtime, allowances, team and unit membership. It does not stop at the first one that fails; it reports every broken rule at once. Pick a scenario below, or set the qualifications, shifts and duty pattern yourself and press Check this swap.

Turn on JavaScript to change these controllers, dates and duty patterns. The worked example below already shows every check.

Controller A
Shift
Controller B
Shift

Allowed: all 24 checks passed.

Roster integrity

The two sides of the swap have to be a coherent, exchangeable pair in the first place.

3 passed

  • Pass
    Blocks aligned

    Both blocks are the same length and cover the same dates.

  • Pass
    Same roster

    All shifts belong to the same published roster.

  • Pass
    Shifts must differ

    The two sides differ in date, shift type or qualification.

Eligibility and qualifications

Both employees must actually be allowed to work the shift they are about to receive.

2 passed · 2 not applicable

Organisation and team

A swap cannot move work across an organisational boundary the employee does not belong to.

1 passed · 2 not applicable

  • Not applicable
    Same employee category

    Both fictional controllers are modelled as the same employee category.

  • Not applicable
    Team membership

    Neither shift here is bound to a specific team.

  • Pass
    Unit membership

    Both employees hold membership in the unit of every shift they receive.

Fatigue and rest

The resulting schedule still has to be safe to work.

2 passed

Absence and conflicting requests

The shifts must not already be spoken for by leave, duty, or another pending request.

4 passed

Pay, allowance and limits

A swap must not quietly move money, banked hours, or monthly quotas between two people.

1 passed · 7 not applicable

Both controllers here are fictional, and so are their shifts and duty patterns. No customer data appears anywhere on this site.

The same 24 checks run three times over a swap's life, once while browsing candidates, once the instant it is submitted, and once again when an approver clicks Accept, because the roster can change between any two of those moments. Full mechanism at shift swaps →.

Stage 3 of 7 · Eligible approvers, computed live

Who can act on a step is recalculated every time, not frozen at submission

Underneath, leave, duty, swap, work requests and shift extensions are all the same concept: an ordered list of approval steps, each naming one or more eligible-approver mappings, membership scope, an optional specific role, and optionally the unit's Primary Head of Unit by name. Both worked examples resolve this the same way.

Where the chain lives

For the swap, on the unit that owns the roster the swapped shifts belong to. For the work request, the same, the unit owning the roster it was raised against.

Computed now, not then

If a team manager changes on Tuesday, a request submitted Wednesday is checked against Wednesday's org chart, not whoever held the role when the chain was configured.

A chain with nothing configured

Resolves to an empty chain, which means the request auto-approves on creation. A real, reachable state, some organisations genuinely want a type to need no sign-off at all. configured

Stage 4 of 7 · Each step resolves

Pending until every step accepts. Rejected the moment one does not

A step that only the requester or the affected employee can satisfy fires automatically at submission, so a chain that opens with self-consent never makes anyone click twice. For a swap specifically, the count of these personal-consent steps must be exactly 0 or 2, never 1, either nobody's individual sign-off is required, or both counterparties must personally agree.

Force Approval

A manager filing on someone else's behalf can tick Force Approval to create the request already approved, with every step recorded against the filer. That option is never available for a request on your own name.

A document that must exist first

Leave and duty types can require an uploaded document, either to submit at all or at one specific approval step. A manager declining an invalid one resets to step one and keeps the request Pending, never Rejected, so nobody has to refile from scratch.

Stage 5 of 7 · The roster changes

Approval is not the end of the request. It is the roster's cue to move

The swap, exchanged

On approval, the two shifts are physically exchanged in the published roster. Any work request or shift extension already attached to either shift transfers to its new owner, along with its accounting. A still-pending or rejected swap can be reverted, unwinding the lock both shifts held during review.

The work request, installed

On approval, the employee's rest-day cell updates in place with its own icon marking it request-originated, and the change publishes into the live baseline automatically, no reopening the wizard. It is fully reversible: revoking an approved work request reverts the published roster and logs the reversal.

Stage 6 of 7 · Balances move

Nobody classifies the hours by hand. The system decided that at approval

Approving the work request triggers an automatic split: if the employee's Bank of Working Hours balance covers the whole extra shift, the whole thing books as banked hours; a zero balance books it as pure overtime; a partial balance splits it, part banked, the remainder priced as overtime. Either the employee, at creation, or a manager, at acceptance, can force the whole thing onto the overtime path instead.

For the swap, if the shift that changed hands was itself obtained through a work request, its Bank of Working Hours or overtime accounting does not stay with the person giving it up, it moves to whoever receives it, re-validated to confirm they have the balance or the overtime headroom to accept the transfer. For a multi-shift swap the change is computed net across every shift in the exchange, so a swap that balances overall can pass even if one leg looks unbalanced alone. Full mechanism at leave and duty → and shift swaps →.

Stage 7 of 7 · Payroll sees it

The line that started as a tap on a phone ends as a coded entry in an export

Whatever stage 6 decided, banked or overtime, flows straight into the payroll engine's overtime pipelines without anyone re-deriving it from the roster by hand: the work request's hours resolve to a payroll code the moment the month's draft export runs, and the swap's transferred allowance moves with the shift it travelled on. See month end for the reconciliation and export this eventually becomes.

Bring your own approval chains and your own swap rules.

Every organisation configures these differently. Bring your actual policy to a working session and we will show you the exact chain, and the exact swap checks, it becomes.