Forward-Only Planning

Why days before today are read-only, what stays editable, and how to correct records when something about a worked day is wrong.

Forward-Only Planning

The scheduler is a forward planner: you plan the future; the past is governed by what actually happened. Days before today are visible on the board but read-only — no adding, no removing, no dragging into them. Today and everything after it are fully editable.

The rule in one line

The schedule is the plan; the timesheet is the record. You can correct the record until it's processed, with an audit trail. You can't rewrite the plan after the day's been worked — because the plan is evidence.

What this looks like on the board

  • Past days are tinted, show no add controls, don't accept drops, and their chips are frozen (you can still click a chip to view its details and signals). Unfilled past demand shows neutral — it isn't actionable, so it doesn't alarm.
  • Today is highlighted and fully editable. A worker calls in sick at 6am? Swap them out. Job runs long? Extend the allocation. Today belongs to dispatch until it's over.
  • The rule is enforced by the system itself, not just hidden buttons — a past day genuinely can't be changed.

Why

Pay's schedule feeds payroll. Once workers file timesheets against allocations, an editable past plan becomes a way to quietly change the context those timesheets were filed in — and it destroys the plan-versus-actual comparison that scheduling reporting depends on. Keeping the past intact means:

  • Disputes have evidence. "We scheduled you Tuesday, you didn't show" is only answerable if Tuesday's schedule can't be rewritten.
  • Reporting is honest. No-show rates, chronic reshuffling, and under-planning are only visible if the original plan survives.
  • Nothing disappears silently. Yesterday's schedule can't be edited into a different story after the fact.

"But something about yesterday is wrong" — the correction workflows

Everything correctable is corrected on the record side:

SituationWhat to do
The hours/activities on a filed timesheet are wrongEdit the timesheet (workers can edit their own while it's still pending; dispatchers can edit in the Timesheets module). Every change is recorded in the audit history.
The scheduled worker didn't work, someone else didThe person who worked files a timesheet — from My Shifts as an unscheduled entry, or the dispatcher enters it in the Timesheets module. The wrongly-scheduled worker simply doesn't file (or their pending timesheet is removed). This works whenever you find out — the day after, or the week after; filing is open for any past day.
You realise mid-morning today's plan is wrongToday is editable — fix it on the board. This is the intended workflow: fix the plan the day it changes.
A worker worked a day they were never scheduledThey file an unscheduled timesheet from My Shifts for that day (allowed for today and past days).

Payroll and invoicing flow entirely from timesheets, so in every scenario the money ends up correct without the historical plan being falsified.

A worked example: Steve was scheduled Tuesday, didn't show, and Dave covered — and you only hear about it Wednesday. Steve files nothing (his shift just stays unfiled — that's the honest record of a no-show). Dave files an unscheduled timesheet for Tuesday from My Shifts, or you enter one for him in Timesheets. Dave gets paid, the client is billed for who actually worked, and the schedule still shows that Steve was the one booked — which is exactly what you'll want to see the next time it happens.

Editing an order that has already been worked

Orders stay fully editable — dates, resources, quantities, times. The forward-only rule shapes when your edits take effect, not whether you can make them:

Every resourcing edit takes effect from today forward; days already worked keep the shape they had.

  • Removing a resource, turning a day off, or moving the dates never happens silently. If the change would stand down people who are already scheduled, you're shown exactly who and how many upcoming allocations are affected before anything is saved — confirm to proceed, or cancel and nothing changes at all. Days already worked, and any timesheets filed against them, are never touched.
  • Changing a resource's quantity or times applies from today. The system keeps a note of what each past day looked like, so editing the plan going forward can't rewrite history — last month still shows the crew size and hours that were actually asked for then.
  • Adding a new resource starts from today. It doesn't appear on days before it existed.

In the order's resource editor, the past is visible but not editable: the editor opens at the current week, with earlier weeks tucked behind a history section you can expand to see each past day's shape — marked historical, shown as a record rather than a form.

What stays visible

Read-only doesn't mean hidden. You can page back as far as you like to review what was scheduled — the past is a reference, not a black hole. Past allocations keep their role and order context even if the underlying resource has since been removed from the order, and past days keep showing what was planned even after the order's pattern or dates change.