Working with requests
Capture the work that needs scheduling — create requests, nest them into containers, and manage them as a tree or a list.
The Requests page (“Organize tasks and groups and track their schedules.”) is where work enters Orkyo. A request records what needs to happen, what it requires, and — once scheduled — when and where it happens.
Two views
Switch with the View mode toggle:
- Tree view — requests in their parent/child hierarchy. Expand all / Collapse all manage large trees, and a search box narrows to matching requests (their parents stay visible so you keep your bearings).
- List view — a flat list; better for scanning and bulk review. Its column headers sort and filter — by kind, status, schedule or duration — like every list in Orkyo (see Sorting and filtering lists).
The same requests appear in both; pick whichever fits the moment.
Creating a request
Choose New Request (an empty page offers Create Request directly). New from routing creates a whole work order instead: a container with one request per operation, chained in order (see Routings). The form’s Details tab gathers what the request is and what it needs:
- Basic Information — name, description, and an icon.
- Schedule (Optional) — a start and end, if you already know them. Leaving it empty keeps the request in the unscheduled backlog for the Utilization board to place later.
- Requirements — the criteria a hosting resource must satisfy, using the vocabulary from capability matching.
- Resources — what kind of thing the request needs, and which one. Needs lists the resource types your workspace has activated or defined; ticking one adds a picker for it below. A request holds one resource per type, so a job needing a room and a van names both.
- People — who is needed, on the same tab beneath the pickers. People work differently: a request carries as many as the work takes, so they are added here rather than through Needs. Orkyo validates assignments as you edit and reports issues by name (“No issues found” when clean).
- Scheduling Constraints (Optional) — “Specify time windows when this request can be scheduled”: an Earliest Start and/or Latest End that manual and auto-scheduling must respect.
Save with Create Request; editing an existing one ends with Update Request.
Containers and child requests
Requests nest. Use the Children tab — or Add Child Request — to break work down; the parent becomes a Container whose children carry the actual schedules.
When a container holds more than one child, the Children tab shows Sequence these tasks. It opens the plan of that container. The sequenced children are cards joined by arrows, with a padlock on every task that can not start yet. The rest are in an Unsequenced list beside them. See Sequence the tasks in a plan.
A container can declare a Boundary Window (Optional): “Children must start and finish within this window.” The form also shows the container’s Derived Schedule (read-only) — the envelope of its children’s schedules — so the parent always reflects reality.
Use containers for projects, recurring programs, or any batch of related work that should be reviewed — and time-boxed — as one unit.
Dependencies
The tree says what a request is part of. A dependency says what must happen first, which is a different question. Use the Dependencies tab on a saved request to record that it can not start until another request has finished.
Add a predecessor, and give it a Gap if the work must settle first — paint that has to cure, a part that has to cool. Orkyo plans in minutes, so a gap of four hours delays the successor by four hours. A gap can only delay a successor, never pull one earlier.
The tab lists both directions: what this request waits for, and what waits on it.
A request that waits for more than one thing also gets a Can start when control. It says how many predecessors the request waits for: All predecessors, Any predecessor, or At least a number you choose. The default is all of them. A canceled or deferred predecessor leaves the set, so abandoned work never holds a request shut. See Dependencies and the critical path.
Orkyo refuses to move a request to In progress while its start condition is unmet. The message names the work that the request waits for.
Only schedulable requests — leaves — can carry a dependency. A container’s dates come from its children and it never reaches the scheduler, so Orkyo refuses the link rather than record a promise it can not keep. For the same reason, a request that carries dependencies must lose them before it can become a container.
Orkyo also refuses a request that waits for itself, and any link that closes a loop: if B waits for A, then A can not be made to wait for B, directly or through a chain of other requests.
Precedence crosses group and site boundaries, so a request in one group can wait for work in another. That is normal. Dependencies and the critical path covers the model, what the scheduler does with it, and how the critical path is computed.
Validation, up front
The form validates continuously against the same rules the scheduler enforces: resource type mismatches, missing capabilities, overbooking, absences, site mismatches, and more, each named explicitly (e.g. Required capability missing, Overlaps with a holiday). Dependency links are checked the same way: Orkyo refuses a self-link, a loop, and a link on a container. Fixing issues at capture time is far cheaper than firefighting conflicts after placement.
From capture to schedule
Captured requests appear in the Utilization board’s Requests panel, ready to drag into place — or to hand to auto-scheduling in bulk. For the full first pass, follow Create your first schedule.