---
title: "Routings"
description: "A routing is the ordered sequence of operations that converts components into a finished product."
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Routings
A **routing** is the ordered sequence of operations that converts components into a finished product. It tells production _where, in what order, and for how long_ the work happens — the time-and-process counterpart of the bill of materials, which describes _what_ is consumed.
Routings are master data. When a work order is released, it copies the routing's operations into its own list, freezing the as-released sequence so subsequent edits don't disrupt in-flight production.
## Creating a Routing
To author a new routing:
1. Navigate to **Manufacturing > Routings** in the sidebar.
2. Click **New**.
3. Fill in the header:
- **Routing #** — Unique identifier (e.g., `ROU-2026-0042`).
- **Name** — Human label (e.g., `Office Chair Pro routing`).
- **Version** — Engineering version (e.g., `v1`, `rev-A`).
- **Status** — Start in `DRAFT` while you build the operations list.
- **Product** — Optional. The default product/variant this routing applies to.
- **Default** — Mark `Yes` if this routing should be picked when a work order doesn't name one. At most one default per (product, variant) is allowed at any time.
- **Priority** — For alternate routings only; lower number = preferred.
- **Effective From / Effective To** — The date window during which this routing is valid. Leave **Effective To** blank for open-ended.
- **Alternate Of** — If this routing is a second-choice for another routing (e.g., when the primary work center is overloaded), point at the primary here.
- **Supersedes** — If this routing replaces an older version, link to the previous version for the audit trail.
4. Click **Save**. The routing is created in `Draft` status.
## Adding Operations
Operations live on the **Operations** tab of the routing detail page. Click the tab, then **New** to open a dedicated page for the new operation.
Each operation is one step performed at one work center. Fill in:
| Field | Meaning |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sequence** | Order within the routing (e.g., 10, 20, 30). Gaps are allowed so you can insert later (10, 20, 30 → insert 25). |
| **Operation** | Short label (e.g., `Cut tubes`). |
| **Work Center** | Where the operation runs. Choose from your active work centers. |
| **Setup Time (s)** | Fixed batch-level duration in seconds. Incurred once per work-order run regardless of quantity. |
| **Run Time / Unit (s)** | Variable per-unit duration in seconds. Multiplied by the work order's target quantity. |
| **Queue Time (s)** | Buffer before the operation starts. Used by the scheduler only — not absorbed into cost. |
| **Move Time (s)** | Buffer after the operation ends. Same usage as Queue. |
| **Parallelism** | Number of resources at the work center this operation consumes simultaneously (e.g., a two-person assembly takes 2 of the labor pool). |
| **Depends on Sequence** | Optional. Forces this operation to start only after the named sequence completes. Useful for parallel sub-paths within a routing. |
| **Sample Rate** | Fraction of produced units the operation runs against. `1.0` means every unit. `0.1` is typical for QC inspection (10% sample). |
| **Expected Yield** | Fraction of input units expected to pass this operation. Cumulative yield across operations drives the work-order's per-step target quantity. |
| **Subcontract** | Toggle on if this operation runs at an external supplier. See [Subcontract Operations](#subcontract-operations). |
| **Effective From / To** | Per-operation date window. Operations can be end-dated and replaced without touching the rest of the routing. |
| **Active** | Uncheck to retire an operation from future work-order releases while preserving history. |
Each operation is its own page — click **Save** on the operation page to commit it; there is no separate "save the routing" step. Click an operation's name on the Operations tab to revisit and edit it.
The Operations tab's **filter button** narrows by **Work Center**, **Subcontract**, **Active**, an **Effective From** / **Effective To** date range or any of the time, parallelism, yield, lead-time and cost ranges ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)).
## Adding the Operator's Checklist
Once an operation is saved, open the **Instructions** tab on its page to build the operator-facing checklist of micro-steps. Use the operation's **Description** field for the high-level summary of what the step achieves; keep the step-by-step "do this, then this" content in Instructions.
Each instruction is its own page: click **New** to open it (the **Sequence** is pre-filled with the next free gap — highest existing number + 10), and click an instruction's text in the grid to revisit and edit it later.
For each instruction:
| Field | Meaning |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sequence** | Order within the operation's checklist (e.g., 10, 20, 30). Gaps are allowed so you can insert items later. |
| **Kind** | What type of step this is — see [Instruction Kinds](#instruction-kinds) below. Drives what the shop-floor runner shows next to the step (a checkbox, a Pass/Reject pair, or a numeric input). |
| **Text** | What the operator should do — written in their words, the way they would describe the step verbally. |
| **Optional** | Tick if the step does not block the operation when skipped. Useful for traceability hints, photo capture, or extra QC checks. |
| **Estimated seconds** | Optional pacing hint shown next to the step. Independent of the operation's setup and run times — just a guide for the operator. |
| **Min value / Max value** | Only for **Measurement** kind. The acceptance range for the reading. A measurement outside this band is treated as a reject. |
| **Unit** | Only for **Measurement** kind. The unit the operator's reading is in (mm, °C, kg, etc.). Picked from the standard unit catalog. |
| **Rejection blocks completion** | Only for **Quality check** and **Measurement** kinds. When on, a reject (or out-of-tolerance reading) prevents the operation from being marked done until either the reject is overridden or a rework path is taken. When off, the reject is recorded but the operator can still finish the operation — useful for "log a defect, keep going" workflows. |
### Instruction Kinds
The **Kind** field decides what the operator sees on the shop floor:
- **Step** — a plain checklist item. The operator clicks **Done** when the step is complete. Use this for ordinary instructions: "Align the stencil", "Torque the screws to 4 Nm", "Apply label".
- **Quality check** — a pass/fail gate. The operator clicks **Pass** or **Reject + reason**. Pair with **Rejection blocks completion** when a failed check must stop the operation (e.g., "Visual inspection: no solder bridges").
- **Measurement** — a numeric input with optional tolerance. The operator enters a value; if **Min value** and **Max value** are set and the reading falls outside, the item is auto-rejected. Use **Unit** to make the input self-describing (e.g., enter `1.95` with unit **mm** when the tolerance is `1.9 ≤ x ≤ 2.0`).
The Instructions tab is hidden until you save the operation for the first time, since the items need a parent operation to attach to. To reorder, open an instruction and edit its Sequence number — re-sort happens automatically. To delete, use the row's actions menu (or select rows and delete from the toolbar).
Once work-order progress tracking is enabled, the items checked off here are how we measure how far along an operator is in a step (e.g., "5 of 7 mandatory steps done").
### How operator results gate completion
When the WO is running, each instruction collects a **result** as the operator works through the checklist on the shop floor:
- **Step** → the result is recorded as `Done` once the operator ticks the checkbox.
- **Quality check** → the result is `Pass` or `Reject`. A reject requires a reason.
- **Measurement** → the operator enters a number. The server compares against **Min value** / **Max value** and resolves the result to `Pass` (in range) or `Reject` (out of range, with the value preserved for traceability).
When the operator clicks **Complete** on an operation, Beelocity checks every instruction whose **Rejection blocks completion** is on. If any of those still has an active `Reject` result, completion is refused with a "There are unresolved rejections on this operation" message — the operator must re-record the failing step as `Pass` (after the rework that fixed it) before the operation can finalise. Re-recording overwrites the previous attempt but keeps the full history for the audit trail.
Instructions whose **Rejection blocks completion** is off do not gate completion — a reject is logged for the record but the operator can still finish. Use this for informational checks that you want to track without holding production.
The Instructions tab filters by **Kind**, **Optional**, **Active** or an **Estimated (s)** range.
## Operation Time Math
For an operation with quantity `Q` and parallelism `P` running at a work center with efficiency `E`:
```
op_setup_seconds = setup_time_seconds (independent of Q and E)
op_run_seconds = (Q × run_time_per_unit_seconds) / E (efficiency stretches/shrinks)
op_total_seconds = op_setup_seconds + op_run_seconds
op_capacity_hours = op_total_seconds × P / 3600 (parallelism multiplies the constraint draw)
op_cost = op_capacity_hours × cost_rate_per_hour
+ (Q × subcontract_unit_cost if subcontract)
```
Queue and move times are **scheduler-only** — they push the next operation's earliest start later, but they do not consume capacity and they do not absorb cost.
### Example
A `Cut tubes` operation: setup 600 s, run 30 s/unit, parallelism 1, work center efficiency 0.92, cost rate 1200 DZD/hour. For a work order of 50 units:
```
op_setup_seconds = 600
op_run_seconds = (50 × 30) / 0.92 ≈ 1630
op_total_seconds = 2230
op_capacity_hours = 2230 × 1 / 3600 ≈ 0.62
op_cost = 0.62 × 1200 ≈ 744 DZD
```
Use the **Cost Preview** action on the routing detail page to compute this for the whole routing at any quantity.
On the **Routings** list, the **filter button** beside the search box narrows by **Status**, **Product**, **Default**, **Active**, **Priority** or an **Effective From** / **Effective To** date range ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)).
## Routing Lifecycle
Routings progress through four statuses:
| Status | Meaning | What you can do |
| -------------------- | -------------------------------- | ----------------------------------------------------------------------------------------- |
| **Draft** | Being authored | Edit any field; add or change operations; activate when ready |
| **Pending approval** | Submitted to the workflow engine | Approvers review; can return to Draft on rejection |
| **Active** | Released for production | Work orders can reference this routing; engineering changes require a superseding version |
| **Obsolete** | Superseded by a newer version | Historical work orders still reference it; new work orders cannot |
A road runs along the bottom of the routing's page: **Draft → Active**, the same two steps a bill
of materials walks, since the two are written and put into service together. The button beside it
takes the next one.
The other two statuses are not on that road, and are picked from the map behind the status word
instead:
- **Pending approval** is a detour off Draft, for a routing that waits for a reviewer. One that
goes round by it rejoins the road at Active.
- **Obsolete** is the way out, from wherever the routing stands.
Hover a step to read when the routing reached it and who moved it.
Engineering changes are made by superseding, not mutating: end-date the active routing, create a new version with the next version label, point its **Supersedes** field at the previous version, and activate it. Re-exploding a past work order continues to use the routing it was released against.
## Subcontract Operations
When a step is performed by an external supplier (powder coating, electroplating, heat treatment, screen printing, etc.), model it as a subcontract operation:
1. The **Work Center** must be a work center marked as Subcontract (with a Default Partner).
2. Toggle **Subcontract** on the operation.
3. Fill in **Supplier Lead Time (days)** — the cycle time the supplier quotes. The scheduler uses this in place of setup + run time.
4. Optional: **Subcontract Partner** to override the work center's default supplier on this operation.
5. Optional: **Subcontract Unit Cost** — the per-unit price the supplier charges. Flows into the cost rollup as a direct cost, separate from labor + overhead absorption.
The Cost Preview shows subcontract costs broken out from labor and overhead.
## Default and Alternate Routings
A product can have multiple ACTIVE routings:
- **Default routing**: The one Beelocity picks when a work order doesn't name a routing. At most one default per product/variant. To swap the default, deactivate the current default before marking the new routing as default.
- **Alternate routing**: A second-choice routing the scheduler may suggest when the primary's work center is overloaded. Point the **Alternate Of** field at the primary routing and set a **Priority** (lower = preferred).
Alternates are never picked automatically at work-order release — they're explicit operator overrides. The scheduler may _recommend_ an alternate when a capacity check finds the primary infeasible.
### Seeing a product's routings
Open the product from **Products**. If the product has at least one routing attached, a **Routings** tab appears alongside Overview / Variants / Units. The tab lists every routing attached to that product, with a **Role** column that tells you at a glance whether each one is the _Default_, an _Alternate of_ another routing, or a _Primary_ standalone (a draft or obsolete version). Click a routing number to open it. The list is read-only — create, edit, and activate routings in the **Routings** module — and its filter button narrows it by **Status**, an **Effective From** range or **Active**. The tab is hidden for products with no routings, so a missing tab simply means none have been authored yet.
## Cost Preview
To preview the cost of running a routing for a specific quantity:
1. Open the routing detail page.
2. Click **Cost Preview** in the action bar.
3. Enter the quantity (e.g., `100`).
4. Beelocity computes the per-operation breakdown and the total — labor + overhead, subcontract, and grand total — using each operation's work center efficiency and cost rate.
Use this when validating a quote, sanity-checking after a work-center cost-rate update, or comparing alternate routings.
## Common Pitfalls
- **Activating a routing without operations.** A routing with zero active operations cannot be activated — you'll get an error. Add at least one operation in `DRAFT` status before transitioning.
- **Forgetting parallelism on multi-person ops.** A two-person assembly with `Parallelism = 1` will under-cost the operation by half. Always set parallelism to the actual headcount drawn from the work center.
- **Editing an Active routing.** Active routings are read-only. To change the recipe, create a superseding version: end-date the current routing's `Effective To`, create a new version with the next label, point its **Supersedes** field at the old routing, and activate it.
- **Mixing standard and subcontract on one operation.** An operation is either fully internal or fully subcontract. If a step is partly outsourced (e.g., overflow during peak), model it as two alternate routings — one all-internal, one with the subcontract op — and let the planner pick.
Source: https://docs.beelocity.com/en/manufacturing/routings/index.mdx