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.
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.
Scheduling
The scheduling view displays the work order as a Gantt chart. Its timeline begins at the work order's scheduled start. A work order's scheduled end is calculated by the latest end date of its scheduled tasks and nested work orders.
Unlike the procedure timeline, the work order timeline also supports assigning task owners. Dependencies cannot be changed during normal execution. They can be changed only when the entire work order is under redline, which prevents an unreviewed dependency change from altering the execution order or schedule.
Users must have permission to update work order timelines before they can edit the schedule.
Kanban
The Kanban view groups work order tasks into columns by status, owner, or location. Change the grouping to focus on execution progress, individual workloads, or where work is being performed.
In the Kanban view, drag a task between columns to update it's status. Blocked tasks cannot be started until the tasks that are blocking them are completed.
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 issues associated with the work order and displays their current statuses. It also shows the total number of associated issues currently affecting the work order.
Create an issue from a work order or task to retain that execution context. An existing issue can also be associated with the work order or task.
The task may be put on hold because of the issues found during execution. More details on holds can be found here: affected records.
An issue may require a redline when its remedy changes work planned. See Redlines for the rules governing those changes.
Work order holds
A hold prevents a work order or work order task from starting until the task or condition blocking it has been resolved. Holds use the same system as issue and inventory holds, so an issue can place a Hold on a task and stop that step from being executed.
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 may connect tasks across otherwise unrelated work orders. It does not modify the procedure or its planned dependency graph.
During a work order redline, a user can add a step and configure it as blocking another step. This makes it possible to introduce corrective or follow-up work that must be completed before an existing task can proceed, even when the tasks were not connected in the original procedure.
Creating, changing, and releasing manually managed holds requires the corresponding permission. Users without that permission cannot manage these execution blocks.
Redlines
A redline is a documented deviation from the procedure used to create a work order. During normal execution, users cannot modify work instructions, data fields, tasks, or dependencies. A redline provides a reviewed path for making those changes while preserving traceability.
A redline may apply to one task or to the entire work order. After a redline has been submitted, further changes require a new redline.
Task redlines
A task redline allows users to change the task's work instructions and data fields. Opening a redline blocks the task from execution until the redline is resolved.
A new redline begins in Draft, where fields and instructions can be added, edited, or removed. When the edits are ready, move the redline to In review. A rejected redline should be returned to Draft so that it can be revised. After approval, submit the redline to apply its changes and unblock the task.
The reviewer specifications are configured at the organization workspace level. See Review and Approval for related workspace-wide configuration.
Work order redlines
A work order redline allows users to add or remove tasks and change task dependencies. It blocks every task in the work order until the redline is resolved. Work order redlines follow the same draft, review, approval, and submission workflow as task redlines.
Canceling a redline
Canceling an unsubmitted redline restores the task or work order structure that existed before the redline was opened.
Merging a redline into a procedure
After a task or work order redline is submitted, its changes can be merged into the original procedure. Factorial creates a new draft procedure revision for the merged changes. That revision must complete the procedure's review and approval process before it can be released.
Once released, the new revision becomes the default for new work orders. Existing work orders remain on their current revision unless a user explicitly applies the new revision.
A redline cannot be merged while the procedure already has an open draft. Release or cancel the existing draft before merging the redline.
Merging a redline into other work orders
A submitted task redline can be merged into tasks on other active work orders.
The source and target tasks do not need to originate from the same procedure step. Merging a redline into a task permanently clears the data on that task, even if the merge is later canceled.
Applying a redline to other work orders requires approval. To minimize reviewer burden, a single approval can cover the same redline applied to multiple selected tasks.
Location
Each task has an execution location. Factorial displays it on the task page and on task cards in the work order, Kanban, and timeline views.
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 timeline, 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.
Data input
Data fields and data tables configured on the procedure step become inputs during work order execution. Operators enter or capture values while performing the work. Some values may be required by the procedure. A task with an incomplete required field cannot be completed.
Read more at Fields and automated data capture from tools and machines.
Comments
Each task has a comments section. The comment counter at the top of the page shows the number of comments and links directly to the discussion and can be clicked to jump directly to the comment section.
Use comments to coordinate work that does not belong in the controlled procedure instructions. Mention another user with @ to send that person a notification.