Shifts
Shifts define when work happens. They provide the time structure that requirements and schedule coverage are built around.
Roster | Mon 17Covered8 / 8 | Tue 181 open7 / 8 | Wed 19Covered8 / 8 | Thu 202 open6 / 8 | Fri 21Covered8 / 8 |
|---|---|---|---|---|---|
| 1st Shift | 1st Shift | 1st Shift | 1st Shift | 1st Shift | |
Team Alpha 4shown4 assigned | |||||
Alex Morgan | SITE-A | FIELD | SITE-A | STDBY | OFF |
Jordan Lee | FIELD | SITE-A | FIELD | SITE-A | OFF |
Taylor Reed | SUPPORT | ABS | SUPPORT | FIELD | SITE-A |
Casey Brooks | STDBY | SUPPORT | SITE-A | — | SUPPORT |
Use this guide when you need to
- Create the time windows the planner uses for staffing and reporting.
- Keep shift names consistent so requirements and schedules stay readable.
- Retire or simplify unused shifts so the editor does not get cluttered.
Jump to section
Purpose
Make shift definitions match the real operating day
- Provide the time blocks that requirements attach to.
- Make weekly schedules easier to read by separating distinct duty periods.
- Support consistent reporting and planning language across the workspace.
Workflow
Set the time model before building coverage
- Create the real shift windows your team actually uses.
- Name them in a way that is clear in requirements, schedules, and exports.
- Return to Edit Requirements after adding or changing shifts so counts stay aligned.
- Review schedules to confirm the shift structure matches how leadership expects to see coverage.
Time model
Overnight shifts should still read like one operational block
A shift that starts at 22:00 and ends at 06:00 crosses midnight, but planners still think of it as one shift. Define it consistently so coverage, public schedules, and member expectations all point to the same operational window.
- Use clear names that survive outside the dashboard.
- Avoid duplicate shifts that differ only by wording.
- Confirm overnight boundaries before requirements are built around them.
Guidance
Shifts are the time backbone behind requirements and assignments
A clean shift model prevents the same duty from being interpreted differently across requirements, schedule rows, and public views.
Why clear shift structure matters
The more ambiguous the shift structure is, the harder it becomes to explain coverage. If the organization really thinks in day, swing, and overnight windows, the workspace should reflect that rather than forcing generic buckets that no one recognizes.
How to keep the shift table readable
The shifts page should stay compact and legible. If a shift is no longer part of your planning model, retire or archive it instead of leaving the requirements matrix cluttered with outdated structure.
How shifts interact with requirements
Requirements are set by role on a shift. That means the shift list is one of the main dimensions that shapes how large or complex the coverage matrix feels. Cleaner shifts usually produce a cleaner requirements editor.
Practical notes
Shift setup checks before you add requirements
- Keep shift labels short enough to fit in tables and summary strips.
- If the requirements matrix feels bloated, review whether every shift still belongs there.
- Use consistent names across the whole workspace.
Questions
Questions schedulers ask about shift structure
Overnight work, team-specific operating windows, and how much shift detail is actually useful.
Can RoleSchedule handle overnight shifts that cross midnight?
Yes. Overnight windows such as 22:00–06:00 can be modeled as one operational shift. The important part is defining the start and end consistently so requirements, assignments, and public schedule views all describe the same work period.
Can different teams use different shifts?
Yes. The organization can define the shift structure it needs, while groups, requirements, and schedules determine how those windows are used in practice. You do not need to force every team into one identical weekly pattern.
Should I create a new shift for every small time difference?
Usually not. Create shifts that represent real recurring operating windows. Too many nearly identical micro-shifts make requirements and schedule editing harder to maintain.
What should I set up first: shifts or roles?
Set up the basic shifts early because they define when work occurs, then define the roles that describe what must be covered during those operating periods. Both should exist before you build meaningful coverage requirements.