Appearance
Work orders
Table of Contents
A work order is an instantiation of a released procedure revision. It records the work performed, the people who performed it, the materials used, and the data collected during execution.
This page breaks work order documentation into two parts:
- Management includes ownership, scheduling, kitting, issues, and approved deviations from the procedure.
- Operation includes following instructions, recording labor, fulfilling part requirements, entering data, and collaborating with other operators.
Management
Creating a work order
A released procedure must be selected for every new work order. The work order inherits the selected procedure's action and output part. During creation, specify the output quantity and assign an owner. For build procedures, you may specify whether you are creating a brand new inventory item or using an existing inventory line item. For serialized or lot-tracked parts, enter an existing serial or lot number, manually input one, or allow Factorial to generate one from the scheme configured for the part.
You can create a work order from the work orders list or with Cut work order on a released procedure. Once it is created, Factorial opens the new work order.
The work orders list shows open work orders by default. Pick Completed or Canceled in the Status filter to include them. When the list is empty, it says which work orders are hidden.
For prototype or one-off work that does not yet have a released procedure see the projects documentation.
NOTE
By default, Factorial does not instantiate every nested work order when the top-level work order is created. This prevents unready work from appearing in operator queues. An advanced creation option can instantiate all nested work orders immediately when the manufacturing plan requires them up front. See nested work order instantiation for details.
Archiving a work order
Factorial does not allow work orders to be deleted. A work order may contain execution records needed for traceability, and deletion would cause irreversible data loss.
Archive a work order instead, which preserves the work order and its history. Archived work orders can be unarchived.
Task details
Each task displays execution-specific details that are not part of its procedure definition:
- Owner identifies the person responsible for the task.
- Location identifies where the task will be performed.
- Linked Kit(s) indicates kit(s) that were made for the task.
Select the kitting indicator to open the kitting modal. The indicator does not appear when a kit is not required or when the task's part requirements have already been fully actioned.
At the top of the task details, next and previous buttons move between the work order's tasks in the work order's order. Nested work orders are skipped.
Work order page
The work order page shows the work order's title, procedure revision, status actions, and connected inventory. Select the revision number beside the title to open the procedure. Copy Markdown copies the whole work order as Markdown.
The connected inventory is the inventory the work order builds or works on. It appears beside the title on every tab, so the unit being built is always in view. When the inventory belongs to a parent work order, the page notes that it comes from the parent. Select an inventory item to open it.
Four tabs below the header show the same work order in different ways:
- Overview lists the work order's tasks and nested work orders, its discussion, and its details. The tab counts completed items. Select View history in the details to open the work order's history.
- Kanban arranges the items in columns by status. See Kanban.
- Timeline shows how the work was carried out over time. See Execution timeline.
- Materials compares installation requirements with the inventory installed so far. See Material progress.
The header updates live on every tab while other people work on the work order. The timeline and material progress are snapshots instead: they stay as they were when the page loaded, so the view does not shift while you read it. Select Refresh on the timeline, or Refresh ABOM on material progress, to take a new snapshot.
Kanban
The Kanban tab arranges the work order's tasks and nested work orders into one column per status: To do, In progress, Completed, and Canceled. Each column shows how many items it holds.
Drag an item between columns, or use its status picker, to change its status. Factorial saves the change before the board updates, so a move that is not allowed leaves the item where it was. Blocked tasks cannot be started until the tasks that are blocking them are completed.
Execution timeline
The execution timeline shows how a work order was actually carried out. Select the Timeline tab on the work order page to open it. The timeline is read-only and is built from the work order's recorded history. The plan it compares against comes from the procedure's timeline.
Each row is the work order, one of its tasks, or a nested work order, indented under its parent. A row's bar is split into the statuses the item passed through: To do, In progress, Completed, and Canceled. A nested work order that has not been instantiated yet shows a dashed Pending span. Statuses can move backwards, so a task that was started, returned to To do, and started again shows two In progress spans. A completed or canceled item ends in a short cap at the moment it finished.
The timeline also shows:
- Holds as hatched spans from when each hold was placed until it was released.
- Redline markers each time a redline on the task was opened, sent to review, applied, rejected, or canceled.
- Markers for inventory installed or consumed on a task. Items recorded together appear as one marker with a count.
Select any bar or marker to see who started and ended it, how long it lasted, and how long the item spent in each status. The details link to the item and to its full history.
Processing time
The summary above the timeline measures the whole work order, including its nested work orders:
- Lead time runs from when the work order was created until it was completed or canceled. While the work order is open, it runs until now.
- Processing runs from the first time any task in the work order started until the work order finished.
- Hands-on is the time during which at least one task was In progress. Two tasks worked at the same time count once.
- Task time adds up every task's time In progress, so parallel work counts once per task. Dividing task time by hands-on time gives the average number of tasks worked at once.
- On hold is the time during which at least one task was held.
- Planned is the duration the procedure's estimated durations allow, with how far the actual start and processing time differ from it.
Gaps between hands-on time and lead time point at waiting: tasks queued in To do, held for a redline, or blocked by earlier work.
Viewing options
Zoom with the zoom buttons, the + and - keys, or Ctrl or ⌘ while scrolling. Fit returns to the whole work order. Planned draws each item's planned span behind its bar. Collapse idle time narrows stretches when no task was in progress, so long weekends or queues don't squeeze the active work into a sliver. Collapsed nested work orders show a thin strip under their bar wherever anything inside them was in progress.
The timeline is built from the work order's recorded history. Items created before Factorial recorded work order history start at their first recorded event, and the page notes when that happens. A single timeline shows up to 2,500 work orders and tasks; open a nested work order's timeline for larger trees.
Material progress
Material progress compares a work order's installation requirements with the inventory actually installed on its output, the as-built bill of materials (ABOM). Select the Materials tab on the work order page to open it. Requirements come from the part requirements on each task's step, including steps changed by approved redlines, and from the work order's nested work orders.
Material progress measures material fulfillment, not task completion. A requirement is fulfilled once enough matching inventory is installed on the output, whether or not its task is completed.
Requirements are grouped by output inventory. Each requirement shows the quantity required, installed, and remaining, counted from the inventory its task installed against it on the task page. Expand a requirement to see that inventory, marked when a substitute part was used.
Inventory on the output that no requirement here was filled with is listed under Installed on no current requirement and does not count toward fulfillment: inventory installed outside a task, by a task of another work order, or against a requirement a redline since removed or changed to another part.
Some work is not counted:
- Nested work orders that have not been instantiated yet. The page notes how many are pending.
- Installations on output inventory that became inactive after a split or merge. Its current split or merge descendants are counted instead, so the same material is not counted twice.
Material progress covers up to 1,000 work orders, 2,000 tasks, 2,000 installation requirements, and 5,000 installed inventory groups. For larger trees, the Materials tab names the limit reached; open a nested work order's material progress instead.
Nested work order instantiation
Instantiation creates a nested work order from an embedded procedure. Until instantiation, the embedded work remains a reference to the latest released revision of that procedure. Delaying instantiation keeps later not-ready-to-be-worked tasks out of operator queues and allows it to receive newer embedded procedure revisions released before instantiation.
When Factorial instantiates the nested work order, it copies the latest released revision and freezes its contents for execution. Releasing another revision does not automatically modify the instantiated work, though the releaser will be prompted during revision rollout to potentially modify the work order with the latest content. During rollout, users can retain the nested work order's existing revision or apply selected changes from the new revision through a redline. Redlining preserves completed and in-progress work and its execution data, but does not carry it over to the newer revision—since the schema for the execution data may have been altered.
Already instantiated work orders using an outdated version are also flagged with a warning icon during execution. Clicking the icon will open a modal, which allows (if desired) archiving the current work order and redlining in the latest released revision—upon acknowledging that part requirements and data input will not carry over automatically.
Issues
The Issues panel lists the issues linked to the work order or any of its tasks, with their statuses, and shows how many are still open.
Raise an issue from a task to keep its execution context: the task and work order are linked automatically, and the unit being built and the inventory installed on the task can be added as affected records. An existing issue can also be linked to the work order or task.
An issue may place a hold on the task. A rework or repair remedy may change the task, or add a task, through a redline.
Work order holds
A hold stops a work order task from starting or completing until the hold is released. A held task shows an On hold badge on the task page, in the work order's item list, and on task cards, and its In progress and Completed statuses are shown disabled with the reason. While a hold's redline is still open, the badge also has a red In redline part.
A task can have several holds at once. Each hold records why it was placed, who placed it, and when, and stays on the record after it is released. Placing and releasing a hold are recorded in the work order's activity feed.
Holds are separate from the things that place them. Two things place holds on tasks:
- Redlines. Opening a redline on a task holds it, so nobody executes content that is about to change. The hold is released when the redline is applied. When a redline is canceled or rejected, the person closing it chooses whether its hold is released or kept. A kept hold stays until someone with the Work orders permission releases it from the task page. This lets a team stop a redline without also unblocking work that someone should still look at.
- Issues. An issue may hold an affected task. An issue hold is released only through the issue, by an applied disposition, a completed remedy, or an approved cancellation. It cannot be released from the task page. Issue holds ship with dispositions and are not yet available, see issues.
A work order can't be completed while any of its tasks is on hold. Its Completed status is shown disabled with the number of held tasks. Apply, cancel, or reject the open redlines, release the kept holds, or resolve the issues first.
A work order also can't be completed while held inventory is anywhere in the as-built structure of the unit it builds, at any depth.
Canceling a task or work order leaves kept holds and issue holds in place. Un-canceling a task or work order that still has kept redline holds opens a dialog listing them. Choose Keep holds to un-cancel and leave them, or Release holds to un-cancel and release them in the same step, which requires the Work orders permission. Un-canceling through the API or by dragging a task on the work order board keeps the holds; send release_holds: true with the status change to release them through the API. Issue holds are never released by un-canceling.
Holds are different from planned procedure dependencies. A procedure dependency belongs to a procedure revision, contributes to timeline planning, and is limited to items under the same parent procedure. A hold belongs to work order execution and does not modify the procedure or its planned dependency graph.
Manual holds, holds on whole work orders, and holds that connect tasks across unrelated work orders are planned.
Redlines
A redline is a reviewed change to the content of one work order task. During normal execution, a task's instructions and part requirements come from the released procedure revision and cannot be edited. A redline provides a reviewed path for changing them on one work order while preserving traceability. Redlines live on the work order: they never change the procedure.
Only tasks that are To do or In progress, on a work order that is To do or In progress, can be redlined. Completed and canceled tasks keep what they ran.
Opening a redline
Select Redline this task on the task page and give an opening reason. The reason is required, so every change records why it was made.
Opening a redline copies the content the task runs into the redline and places a hold on the task. The redline can change the task's title, description, and every block, including documents, files, inline PDFs, and part requirements.
A task has at most one open redline. Anyone with the Redline permission can open the task's redline and edit it, and people editing the same redline at once see each other's changes live.
Review and approval
Redlines follow the same review workflow as procedure revisions:
- A new redline starts in Draft, where its content can be edited.
- Submit for review moves it to In review, freezes its content, and notifies the reviewers who were requested. Each submission starts a new review cycle, and approvals from earlier cycles no longer count.
- Reviewers approve, request changes, or comment. Only reviews from users with the Approve redline permission count, and approvals from the person who opened or submitted the redline never count.
- To address requested changes, move the redline Back to draft, edit it, and submit it again.
The number of approvals a redline needs is set by the redline review policy, separately from the procedure policy.
Applying a redline
Once a redline has enough approvals and no outstanding change requests, select Apply to task. The task runs the redline's content from then on and its hold is released. The task page links to what the redline changed, and the redline's Changes page compares its content with what the task ran before, block by block.
Applying requires the Redline permission. A redline can't be applied while its task is completed; cancel it instead. Its work order can't be completed while the redline is open, since the redline holds the task.
A later redline on the same task starts from the content the last applied redline gave it.
Rejecting and canceling
A reviewer with the Approve redline permission can Reject a redline in review, with a comment explaining why. The person who opened or submitted a redline can't reject it; they cancel it instead. Anyone with the Redline permission can Cancel a draft or in review redline.
Rejected and canceled redlines are closed for good and stay on the record. A retry is a new redline, started from the task's current content. When closing a redline, choose whether to keep the task on hold or release it.
Canceling a task, or the work order it belongs to, also cancels the task's open redline and releases the redline's hold, since a canceled task never runs the change. The redline records who canceled it and why. An API key can't cancel a task with an open redline; cancel the redline first, or have a user cancel the task.
The review record, including reviews, submission notes, and the reason a redline was closed, can't be edited after it is written.
Planned
The following are planned:
- Work order redlines that add or remove tasks and change dependencies. Until then, dependencies cannot be changed during execution.
- Redlining completed tasks, for documentation fixes or rework.
- Merging an applied redline into a new procedure revision, or into tasks on other active work orders.
- Flagging redlines that have been open too long as overdue.
Location
Each task has an execution location. Factorial displays it on the task page.
The location is also the destination for any kit created for the task. It is mandatory to set it before requesting material so that the kitting team knows where to deliver the kit.
Kitting part requirements
Kitting groups the part requirements for one or more tasks into a request for delivery to an execution location. The kitting status appears in the task details and Kanban views. Select the status indicator to open the kitting dialog.
A kit may cover one task, a selected group of tasks, or all eligible tasks in the work order. Every kit must have one destination location.
Operation
Work order operation is the execution of individual tasks. Operators follow instructions, action part requirements, record data, and track the time spent on the work.
Task Context
The task page displays key execution information above the work instructions and in the right rail. From the right rail, an operator can:
- Open tasks that are blocked by or blocking the current task.
- See the next task in the current work order.
- Assign the task to a queue or move it to another queue.
- See the next unclaimed task in the assigned queue.
Read more about queues.
Tracking Labor Hours
Each task includes a sessions panel for recording labor. A task has one owner, but multiple operators can be checked in at the same time.
The panel shows whether the current user is checked in, the elapsed time for each active session, and the other users currently checked in. Its history includes earlier sessions for work that spans multiple shifts or days.
Users with the required permission can correct their sessions or add a missed session. Each edit requires a reason and appears in the activity feed, preserving a record of the change.
Factorial uses completed sessions to calculate observed execution-duration ranges. These ranges provide feedback for reviewing the estimates configured on procedure steps.
Fulfilling Part Requirements
A work order task contains a frozen copy of the definition blocks from its procedure revision. During execution, part requirements and data inputs use controls designed for recording the work performed. Their underlying definitions remain unchanged unless an approved redline modifies the task.
Each part requirement identifies:
- The required part.
- Acceptable substitutes, when applicable.
- Reference designators, when applicable.
- The required quantity and material action.
Read more specifically about part requirements here
Barcode scanning can be used to quickly identify inventory to fulfill part requirement lines. This reduces manual entry when part numbers and inventory identifiers are long or when a task uses many items.
Each install records the requirement it was installed from. A requirement lists the inventory installed against it, with its trace number, quantity, and the part when a substitute was used, and counts its progress from them. Lowering a requirement's quantity after installing leaves it over installed rather than moving the excess elsewhere: its progress shows in warning color and its material progress status reads Over installed until the excess is uninstalled. Splitting installed inventory keeps every piece on its requirement. A redline carries installs over to the requirements it keeps, as long as the kept requirement still accepts the installed part. Inventory whose requirement a redline removed, or changed to a part that no longer accepts it, is listed under Installed on no current requirement.
Uninstall takes inventory back off, for example after a mistyped quantity, the wrong lot, or a part removed on the floor. Lot and untracked inventory can be uninstalled in part by entering a quantity. Serial inventory is uninstalled whole. Uninstalled inventory returns to available, or to WIP if a work order on it is still open, and the uninstall is recorded in its history against the task. Uninstalling needs the task and its work order open: a completed or canceled task must be reopened first. Unlike installing, uninstalling never starts the task, and holds and unfinished dependencies do not prevent it, so a part a hold was raised over can be taken off. Only inventory the task installed is listed. Inventory installed on the same output from elsewhere shows on the work order's material progress.
Data input
Data fields configured on the procedure step become inputs on the task. An operator records each value on the task page while performing the work. Each input saves on its own and shows whether its value is saving or saved: a checkbox or select as soon as it changes, and a text, number, or date input when the operator leaves it. Leaving the page while a value is saving or not yet saved asks for confirmation first. If a value cannot reach the server, the input says it was not saved. A typed or checked value stays in the input to be sent again with retry, and a select's option is picked again. A number keeps the decimal places it was entered with, so 12.50 is recorded as 12.50, not 12.5. A date or date & time must fall between 1900 and 2199. A date has a Today button and a date & time a Now button, which fill in the current date or time and save it. When someone else is in a data field or a data table cell on the same task, it has a ring in their color with their name. The work order's own fields show the same.
Values are recorded only while a task is in progress. Recording a value on a task that is still to do starts the task, under the same rules as starting it by hand: a held task or one with unfinished dependencies cannot start, so it cannot record values either. Installing inventory starts a task the same way. A completed or canceled task must be reopened before its values can change, so a value cannot change silently after the work was signed off.
A task with an incomplete required field cannot be marked as completed. A required checkbox must be checked. Any other required field must have a value, and a required select or multiselect must have at least one option chosen. The status picker shows which fields are missing. A work order cannot be completed while any of its tasks that is not canceled is missing a required field, because a completed work order's tasks can no longer record values.
Recording, changing, and clearing a value each appear in the task's history with who made the change, the old value, and the new value. When an approved redline is applied, the values already recorded stay with the task on every data field the redline kept. A value whose data field the redline removed, or replaced with a different field, is kept in history but no longer appears on the task.
Each task records values in its own copy of its step's data tables, starting from their initial values. Operators edit the cells like a spreadsheet, and add, reorder, and delete rows where the table lets them. A reference table is read-only on the task. Table values follow the rules of data fields: recording one starts the task, a task with a required column empty on any row cannot be completed, and each change appears in the task's history.
While a task cannot record values, for example while it is held or once it is completed, its data fields and tables show a lock with the reason.
A redline shows each table the task records values in with the task's rows and values. The redline may add, reorder, and delete the table's rows and columns, but not change its values. Rows an operator added on the task are shown with a lock, and the redline cannot change them. Rows and columns the redline adds start empty. When the redline is applied, the task continues with the rows the redline showed and the values recorded in them. Values in a row or column the redline deleted are kept in history but no longer appear on the task. A redline changes a reference table's values like any author.
Read more at Fields and automated data capture from tools and machines.
Comments
A work order page has a conversation below its items. A comment posted there belongs to the work order as a whole, such as a changed due date or a parts shortage. Comments on the work order's own tasks, such as those an integration posts, appear in the same conversation in the order they were written, each linked to its task. Comments on a nested work order stay with that work order.
Use comments to coordinate work that does not belong in the controlled procedure instructions. Mention another user with @ to send that person a notification. The notification opens the conversation.