Appearance
Procedures
Table of Contents
Overview
A procedure defines repeatable work for building, testing, or maintaining a part. It brings steps, instructions, part requirements, estimated durations, and dependencies into one versioned source of truth.
Released procedures provide the reviewed and approved instructions used to create work orders. A work order cannot be cut from a procedure until it is released.
Procedures are versioned. A released procedure revision becomes the default revision for new work orders. Released procedures are immutable.
Creating a Procedure
A new procedure can be created from a blank state, as a copy of an existing procedure, or as a new version of an existing procedure. Its state begins in Draft and can be transitioned to In review to trigger the review process.
Before it can be released, it must satisfy the review requirements configured for the organization.
Deleting or Archiving a Procedure
Factorial does not allow procedures to be deleted. Procedures may be connected to revisions, work orders, review history, and execution data, so deleting one could cause accidental and irreversible data loss.
Procedures that are no longer in use can be archived instead. Archiving preserves the procedure and its history while removing it from the normal views and workflows used by the rest of the organization.
Procedure Output
A procedure may define at most one output. The output is identified by an action (build, test, or maintain); a part number; and a revision.
A procedure cannot build/test/maintain multiple different part numbers. Each part number is associated with a single versioned procedure lineage.
Actions on the procedure always implicitly affect the associated output part if there is one. For example if a procedure outputs Car, and Step 3 Installs Wheel, that means executing the task created from that step would track an install of Wheel onto Car.
To represent a process that produces multiple coproducts, create a parent procedure that embeds one output-producing procedure for each coproduct.
Procedure Outputs for Embedded Procedures
An embedded procedure may specify an output part when it builds a subcomponent. The inventory produced by the embedded work can then be installed into the parent assembly.
This mechanism can be used to organize subassemblies or phantom assemblies.
An embedded procedure that performs testing, maintenance, or another non-producing process may omit its output.
Procedures, EBOMs, and MBOMs
A build procedure connects the engineering definition of an output part to the work required to manufacture it. When the output part has an engineering bill of materials (EBOM), its line items can be assigned (fully or partially) to the steps where they are installed, consumed, or otherwise used.
The aggregate of a procedure's part requirements form the output part's MBOM. Factorial identifies differences between the EBOM and MBOM so that manufacturing engineers can update the procedure or confirm that a difference is intentional. See Part Requirements and MBOMs for the MBOM and comparison rules.
Similar Procedures
Different output parts require separate procedures, even when their manufacturing processes are similar. These procedures can diverge as new revisions are created.
When multiple procedures must share the same process, move the common work into an embedded procedure. The shared process can then be reviewed, revised, and released independently.
Steps
A procedure contains steps. Each step defines a unit of work that is executed as part of a work order.
The appropriate size of a step depends on how the work is performed. As a general rule:
- A step should have one clear owner during execution.
- A step should not combine work that can be performed independently or in parallel.
Separating independent work into different steps allows Factorial to assign ownership, enforce dependencies, and identify opportunities for parallel execution.
Step Content
Each step may contain one or more definition blocks. Definition blocks describe the instructions, data, materials, and supporting information required to execute the step.
Documents
A document block contains formatted instructions. It supports common text styles, lists, links, and collaborative editing.
Multiple users can edit a document block at the same time and see each other's cursors, similar to, for example, Google Docs. The interface displays the cursors or active editing locations of other users as they type or move around the text.
Document blocks are intended for procedure instructions. They do not provide every feature available in a general-purpose word processor.
Data Fields
A data field defines a value that an operator records while executing a step. Examples include a temperature reading, torque value, measurement, or inspection result.
Each data field uses a globally configured field definition. The definition specifies its type and may also specify a unit of measure, available options, requiredness, or other validation rules. Fields configured on a step carry forward to the corresponding task.
A task with an incomplete required field cannot be marked as completed during work order execution.
Use a data field when the step requires a single value. See Field Definitions for supported types and validation rules, and Definition-Specific and Instance-Specific Fields for how fields carry forward to work order tasks.
Data Tables
A data table records multiple rows of structured data. Each column uses a field definition to determine its value type and validation rules.
Use a data table when the same set of values may be recorded more than once during a step. See Data Tables for more information.
Part Requirements
Per-step part requirements tell operators which inventory to install, consume, use, or uninstall. They also tell kitting operators and material handlers when the material is required. See Part Requirements and MBOMs for further information on part requirements in Factorial.
Tool Requirements
Per-step tool requirements tell operators which tools/machines they need to complete the task. Tool requirements also allow you to specify tool subsitutes. For example one procedure step may require any company oven, while another may require only the highest temperature oven in the facility.
File Galleries
A file gallery attaches files to a step. It supports images and other file types.
Images may also be inserted into document blocks. Use a file gallery when files are not plain image files, or use a file gallery when files should be displayed, downloaded, or called out separately from the written document instructions.
Step Right Rail for Metadata
Next and Previous for Procedure
At the top of the right rail, there are next and previous step buttons according to the step positions in the procedure for ease of navigation.
Default Queue
When cutting a work order from the procedure, each task is assigned according to the default queue configured on its step. If no default queue is supplied, Factorial routes the task according to queue filters. For more information, see Queues.
Tag(s)
Tag(s)—global to your organization——may be added to any step. Tags are a flexible feature that can be keyed off of for searching, filtering, queues, and actions. Read more about tags in Factorial here
Estimated Durations
A step or embedded procedure may define an estimated duration. Factorial uses these estimates to display procedure timelines and calculate critical paths.
Dependencies
A dependency specifies that one step or embedded procedure must be completed before another can begin. In Factorial, these dependencies are most often labeled with either "Blocked" or "Blocked By" depending on directionality.
Factorial enforces dependency order during work order execution. A blocked item cannot begin until its blocking dependencies are satisfied.
Dependencies may connect only items that have the same parent procedure. A step inside an embedded procedure cannot depend directly on a step outside that embedded procedure.
This restriction makes embedded procedures portable. An embedded procedure retains its internal dependency graph regardless of where it is used.
Timeline Planning
The timeline view displays procedure steps and embedded procedures as a Gantt chart. It uses estimated durations and dependencies to show when each item can occur.
The timeline identifies work that can be performed in parallel and displays the critical path through the procedure. This makes scheduling constraints and opportunities for parallel execution visible before the procedure is used on the factory floor.
Automatic Layout
Automatic layout calculates the shortest schedule permitted by the configured durations and dependencies.
This calculation does not account for finite labor or equipment capacity. For example, a dependency graph may permit 100 steps to run in parallel even when only four operators or three machines are available. Queues are useful for runtime parallelization decisions.
Embedded-Procedure Timelines
An embedded procedure has its own internal timeline. Factorial calculates the critical path through its child steps and embedded procedures.
When viewing an embedded procedure, the timeline displays timing context from its parent procedure. This shows how much time the parent procedure has allocated to the embedded work.
When viewing a parent procedure, the timeline displays timing information calculated from its embedded procedures.
If the critical path of an embedded procedure exceeds its estimated parent duration, Factorial displays a warning. These warnings propagate through the procedure hierarchy so that inconsistencies can be identified from any level of the top-level procedure.
This information supports both top-down and bottom-up planning. A planner may begin with a target duration for the complete procedure or with estimates for the lowest-level steps.
Duration Analysis
As teams execute more work orders from a procedure, Factorial builds a clearer picture of how long its steps and embedded procedures actually take.
Factorial collects execution-duration data and uses it to calculate an observed duration range. This historical range is displayed alongside the manually configured estimate used for planning.
Users can inspect the work orders and check-in sessions included in the calculation. This makes it possible to identify outliers, correct inaccurate labor records, and understand the source of the observed range.
Configured estimates and observed durations are displayed together in the timeline. Differences between them may indicate that an estimate should be updated or that the underlying process is performing inconsistently.
Review and Approval
Each organization may configure the reviews required before a procedure revision can be released. Users with administrative permissions manage these requirements from Organization Settings.
When a procedure revision moves into review, its contents are frozen. This ensures that reviewers evaluate the same revision that will be released.
To modify a revision that is in review, return its status to Draft. Existing review comments remain associated with the revision when it is submitted again.
Review Comments
Review comments are attached to individual definition blocks. This keeps each discussion connected to the specific content being reviewed.
A review comment may mention another user. The interface displays the time of the comment and the time at which the corresponding definition block was last modified.
Procedures do not use general-purpose comments outside of the review process. Context that belongs permanently with a step should be recorded in that step's definition blocks.
When a procedure has acquired enough reviews to be released, a notification is sent to the procedure owner.
Activity
The procedure activity feed displays changes to the procedure over time. It includes review events, comments, and state changes.
Revision Diffs
For revisions after the first, Factorial displays the differences between the current revision and the previously released revision.
Review mode shows changed steps by default. Reviewers may expand the view to display the complete procedure with changes highlighted in context.
The diff remains available after release so that users can inspect how the procedure changed between revisions.
Releasing a Procedure Revision
After a procedure revision is approved, it can be released.
A released revision becomes the default for new work orders created from that procedure. Releasing a revision does not immediately modify existing work orders, but prompts the user with a UI to control the rollout.
Revision Rollout
The rollout screen lists work orders that use an earlier revision of the procedure. It also displays the status of each work order.
Factorial does not assume how a new revision should affect work already underway. For each affected work order, a user may decide whether to retain the existing revision or apply the newly released revision.
The appropriate action depends on the state of the work:
- A work order near the beginning of execution may be canceled and recreated from the new revision.
- A work order with completed or in-progress work may receive selected changes from the new revision through the redline process.
Redlining applies content from a newly released procedure revision to an existing work order while preserving its execution history.
The revision rollout screen is prompted to the user upon procedure release, but it remains accessible on the procedure's homepage as long as that procedure is still the latest released revision.
Embedded Procedures
An embedded procedure is a procedure used as an item within another procedure.
Embedded procedures make it possible to define shared work once and reuse it across multiple processes. For example, a standard epoxy-application process can be defined once and embedded in every procedure that uses it.
An embedded procedure retains its own:
- Steps and definition blocks
- Estimated durations
- Dependencies
- Part requirements
- Tool requirements
- Review requirements
- Revision history
Internal dependencies remain scoped to the embedded procedure. This allows the same procedure to be embedded in different parent procedures without redefining its dependency graph.
Releasing Embedded Procedure Revisions
An embedded procedure is versioned, reviewed, and released independently from the procedures that contain it.
Releasing a new revision automatically updates every reference to that embedded procedure, including references in released parent procedure revisions. The parent procedure does not require a new revision, review, or release. Its embedded procedure reference always resolves to the latest released revision.
Factorial identifies and displays the affected procedures so that users can understand where the new revision will be used. This update cannot be selectively applied to individual parent procedures.
For example, if several released procedures reference revision 3 of an embedded inspection procedure, releasing revision 4 causes all of those references to resolve to revision 4.
For existing work orders, the result depends on whether the embedded work has been instantiated. Uninstantiated embedded work uses the latest released revision when it is instantiated.
Nested work orders that have already been instantiated do not change automatically. The previously mentioned screen for revision rollout on release prompts users to decide whether to retain the existing revision or apply selected changes from the new revision through the redline process. This preserves completed and in-progress execution data while allowing the new embedded procedure revision to be applied where appropriate.
Step Folders
Steps within a procedure can be organized into folders. Folders can be reordered and steps can be moved in and out of folders. Steps in different folders can block each other. Internally, steps in a procedure are modelled as a flat list, and folders are just visual representation helpful for organizing procedures with lots of steps.