On-Call Scheduling

The shift block is the atom of this product. It appears in the team grid, in the manager creation flow, and in both sibling products - so if each team built its own, the workspace would read as three products stitched together.

Decision - I specified the block itself: an “On call” status pill, the team name above the shift name, and one row per responder carrying their role. Fill and border both derive from a single assigned colour - the border and the secondary role rows are that same colour at −10 lightness - so adding an event type means choosing one token, not picking five values.

In a dense grid colour is read before text, which makes it the highest-leverage thing to standardise - and the easiest thing for three teams to quietly diverge on.

Decision - I mapped every event type to one Polaris token: on-call blue, work shift green, meeting magenta, training yellow, an approved conflict or gap purple, and the alert token for a coverage gap. Time off is locked to grey and cannot be reassigned to another event type, so an absence never competes with a live shift for attention. The dark theme is that same map through a single conversion - HSL −73 lightness - rather than a second set of hand-picked colours.

The manager objective that came up first was “ensure coverage is provided as planned, with no surprises”. Some surprises can be drawn in a cell - an unfilled slot. Others can’t: a responder approved for time off with no coverage, or assigned as both primary and secondary, is a relationship between two facts rather than one block.

Decision - An unfilled slot became its own state - a hatched “Coverage needed” row in the alert colour, with a warning marker on the shift containing it - so a hole is visible in the same glance that reads the rest of the grid. Everything structural goes to a Required actions panel beside the grid: one card per problem, naming its type, the shift and window affected, and what is wrong in plain language, then offering the two things a manager would actually do next - edit the shift, or provide coverage.

Most scheduling actions begin as a question about a person: who is on this shift, and how do I reach them right now?

Decision - Selecting a shift opens it in place - responders in role order, the channels to reach the primary (email, phone, Teams, Slack), and the two actions most likely to follow: schedule an absence, or provide coverage. The escalation path is one link away rather than a separate configuration screen.

Escalation is where trust breaks down fastest. An agent needs to believe an unresolved incident will actually reach someone; a manager needs to verify the rules do what they think they do.

Decision - The escalation path reads top to bottom as a timeline, with the delay before each step on the spine - zero minutes, then an hour - and each level stating exactly who is reached (responder level, named users, groups), on which device, whether the manager is notified, and the retry cadence before it moves on.

“Am I on call right now” and “is next month covered” are different questions at different zoom levels, and one grid density cannot serve both.

Decision - Week is the default for reading a rotation. Day expands into a per-person timeline where absences and pending requests sit inline against the hours, so an approval gap is visible on the row it affects. Month steps back far enough to plan and to spot patterns. The view control is identical in all three, so changing horizon never means learning a new screen.