Auto-scheduling
Hand the unscheduled backlog to a solver, review the proposed placements, and commit only what you accept.
Auto-scheduling places your unscheduled requests automatically — respecting requirements, capacity, availability, and constraints — and shows you the result before anything is committed.
Running it
On the Utilization board, press Auto-schedule unscheduled requests. Orkyo hands the backlog to a solver and opens the Auto-schedule preview: “Review the proposed placements before committing them.”
Reading the preview
The summary line names the Solver used — OR-Tools CP-SAT (the optimizing constraint solver) or Greedy (the fast fallback) — and counts Scheduled vs Unscheduled.
- Assignments — the proposed placements, one row per request: Request, Resources, Start, End, Duration. Resources names one resource per type the request needs, and Duration is the working time it occupies.
- Unscheduled — what the solver could not place, each with a named reason:
- No compatible resource — nothing satisfies the request’s requirements; fix capabilities or requirements.
- Insufficient capacity — everything suitable is full in the available windows.
- Blocked by existing assignments — existing schedules leave no room.
- Invalid duration — the request’s duration cannot fit its constraints.
- Solver limit reached — the solver ran out of budget; re-run, or schedule the remainder manually.
- Waiting on an unscheduled predecessor — too few of the predecessors it waits for are scheduled or part of this run. Schedule a predecessor first.
- Diagnostics — solver details for the curious.
Committing — or not
Apply commits every proposed assignment in one step; Cancel discards the whole preview. Nothing changes until you apply — auto-scheduling is a proposal mechanism, not an autopilot.
If the underlying data changes while a preview is open (someone else schedules something), Orkyo refuses to apply a stale preview: “The scheduling data has changed since this preview was generated. Please close and re-run the auto-schedule.”
What the solver respects
Everything manual scheduling validates, the solver honors by construction: requirements vs capabilities, station capacity, working hours, weekends and holidays, availability events, absences, and each request’s Earliest Start / Latest End constraints. The inputs are documented in Scheduling and availability.
The solver plans in working minutes. A 20-minute operation costs 20 minutes, and a three-day job spans the nights and the weekend in between without consuming them. Five short operations in a row can finish on the same day.
Dependencies bind the solver too. It respects each request’s start condition and it will not do otherwise: requests in the same run are placed in order, and a predecessor that is already scheduled bounds the successor by its finish date plus any gap.
A request that waits for any of its predecessors, or for at least a number of them, waits for the earliest predecessors that satisfy it. It does not wait for the last one.
One run fills every resource type its requests need. A request that needs a mill and a van gets both in the same run, over the same window. A chain that crosses types, saw then mill then inspection, is placed in the same run too.
The type filter on the board narrows a run. Filter Stations to mills, and the run fills only mill slots. A request that already holds a resource of another type keeps its window, and the run fills its open slots at that window.
Getting good results
- Model requirements honestly — the solver can only avoid what the data forbids.
- Keep constraints real — over-tight windows produce Invalid duration and empty results.
- Review the Unscheduled list seriously — its reasons are a diagnosis of your model, not just a failure list.
For a worked run, see step 5 of Create your first schedule, or the batch-oriented Auto-schedule a backlog of requests.