Features/GrandPlanner

02 · The season

Does the season hold?

The planner tells you what happens on Thursday. GrandPlanner takes a whole season — or a window, or a set of productions — and tells you where it breaks: which roles aren't covered, which rooms collide, which rules get bent. You work the answer out in a scenario, then merge the parts you want.

SuiteTurn-on module · your admin decides whether it's on

A · Scenarios

Replan without touching the live calendar.

A scenario branches off the live schedule, scoped to one production or the whole organisation. Nothing gets copied. You edit events inside the scenario and runorder records what you changed, against the state of things at the moment you branched.

The plan you're still arguing about, kept separate

Scenario edits sit as an overlay on top of live data. The live calendar keeps moving underneath — someone else's Tuesday change lands as normal — and the scenario keeps the baseline it branched from, so the difference between the two stays meaningful.

  • Scope a scenario to one production or the whole organisation
  • Branch point stamped at creation; the baseline is captured as you edit
  • Five tabs per scenario: overview, report, diff, conflicts, cherry-pick
  • Overlay a scenario onto the planner to see its changes in place
  • Every scenario action lands in the audit log
Scenarios · GrandPlanner3 scenarios
Season 2026-27 — spring re-plot
org-wide · branched 07-14 · 12 warn · 2 breach
DraftMaria S.
Hamlet — press night a week later
Hamlet · branched 07-22 · 4 warn · 0 breach
DraftLars H.
Macbeth — tech week re-stagger
Macbeth · branched 06-30 · merged 11 of 11
MergedMaria S.

B · The feasibility check

Season-scale, not event-scale.

Pick a season, a date window, or a set of productions, and run the check. It returns findings — warnings and breaches — each attached to the event, person, production, or season it belongs to, and each named for the rule it broke.

Feasibility · Season 2026-27scope: season
Events414
People96
Warn23
Breach4
Role coverage · breach
Macbeth · tech run (Thu 09 · 13:00–17:00) needs 2 × Follow-spot Operator. Nobody qualified is available in that window.
Changeover · warn
Hamlet leaves Main stage Oct 18; Macbeth loads in Oct 19. Your changeover rule wants 3 days. Shift the load-in 2 days later to clear it.

Ten named checks, not "conflict detected"

Role coverage. Room overlap. Room turnaround. Availability collisions. Work-time compliance. Rehearsal lead time. Call notice. Productions that share people running overlapping tech weeks. Productions that share a room with too few changeover days. Department prep and breakdown buffers that collide.

  • Scope: a whole season, a date window, or a set of productions
  • Role coverage counts only people qualified for the role in that window
  • Per-production qualifications override the house-wide pool
  • Deterministic fixes ("shift this event 30 minutes later") apply in one click
  • A result goes stale the moment the plan moves under it — re-run before you act

C · Diff & cherry-pick

Take the three changes you wanted. Leave the rest.

The diff compares three states — what live looked like when you branched, what live looks like now, and what the scenario says — entity by entity and field by field. Apply a change into live, reject it, or leave it sitting.

Per change, not per plan

Where live has moved the same field you moved, that's a conflict, and you pick a side field by field before anything applies. Merge-all exists for when the scenario is simply right — it applies what it can, requests approval for what's gated, and skips whatever is still conflicted.

  • Three-way diff — branch baseline vs live vs scenario, down to the field
  • Apply or reject one change at a time; resolve conflicts field by field
  • Merge all reports what it applied, requested, and skipped
  • Events are what merges today — the rest of the diff is there to read
  • Every apply, reject, and resolution is audit-logged
Diff · Hamlet — press night a week later11 changes
Hamlet · tech run
start 13:00 → 14:30 · room Main stage
Applymodified
Hamlet · extra dress
new event · Oct 17 · 18:00–22:00
Applyadded
Hamlet · preview
live says Oct 20 · scenario says Oct 21
Conflictpick a side
Hamlet · photo call
dropped in the scenario
Rejectedremoved

D · Approvals

Some moves need someone else's yes.

An admin writes the matrix: which action, in which context, needs whose approval. Move an event. Add overtime hours. Reassign a role. Exempt a call. Eleven gated action types, each either left open or routed to named approvers.

Approval matrix4 policies
Move event time
Hamlet · production SM ×1 + department head ×1
Add overtime hours
global · HR group ×1
Reassign role
Technical department · department head ×1
Exempt call
global · any planner-editor ×1

Approvers resolved from the org chart, then frozen into the request

A requirement can point at the stage manager of the production, the head of the affected person's department, HR, a named group, a named person, the affected person themselves, or any planner-editor — with a count for how many must sign. runorder resolves those to real people when the request is made and stores that list, so editing the policy next week doesn't quietly rewrite who was asked.

  • Context: global, a department, a production, or an event type
  • Most specific policy wins; no policy matched means no gate
  • Approvers notified by email and push; approve or decline with a note
  • An approved request replays the change itself — nobody redoes the work
  • Requests expire after a set number of days (seven by default)

Want to know whether next season holds?

30-minute discovery call over Teams. Bring a season that gave you trouble and we'll walk through how GrandPlanner would have read it.

Request a conversation →

Or read about the rest.

Each surface gets the same depth as this page. Click around or head back to the overview.

All features →