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 execution, which prevents an unreviewed dependency change from altering the execution order or schedule. Changing them through a work order redline is planned.
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 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.
Holds are separate from the things that place them. Today a hold is placed when someone opens a redline on the task, 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.
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, or release the kept holds, first.
Canceling a task or work order leaves kept holds in place, since they were kept on purpose. Un-canceling a task or work order that still has kept 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.
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 placed by issues, 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 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.