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.
Finding Procedures
The procedure list can be filtered by status, so drafts, revisions in review, released procedures, and archived procedures can be separated. Revisions in review also show their approval progress, whether changes have been requested, and whether they are ready to release.
To see only the revisions that involve you, use the review center.
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 organization's review policy.
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.
Pasting Markdown into a document block converts it to formatted content, including headings, nested lists, code blocks, and tables. This applies to Markdown copied as plain text, for example from a .md file, a code editor, or a chat. Content copied from a web page or another document keeps its own formatting. To paste Markdown as literal text, paste with Cmd+Shift+V (Ctrl+Shift+V on Windows and Linux). Inside a code block, pasted text is always literal.
A document block can display a table pasted as Markdown, but its toolbar does not offer a way to insert one. Record structured values in a data table, which validates each column against a field definition.
Each editing session saves a version of the document. Select Past Versions in the document toolbar to list them, newest first. Selecting a version shows a read-only preview. Restore this version replaces the current document with the selected version, and the replaced content remains available as a version.
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 configures how many approvals a procedure revision requires before it can be released. Administrators manage this review policy 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. Submitting it again starts a new review cycle. Approvals from earlier cycles no longer count, while change requests remain in effect until they are resolved. Earlier reviews remain visible with the revision.
The procedure owner and the user who submitted the revision for review may comment but cannot approve their own revision, except to withdraw their own change request. The owner and the tags of a procedure can only be changed while it is in Draft.
Submitting a Revision for Review
Select Ready for review on a draft revision to open the submit dialog. The dialog collects two things:
- The reviewers to ask. The picker offers the users who hold the Approve procedure permission, since only their reviews count toward the policy, and Show everyone widens it to all active users. Reviewers are saved as they are picked, so a revision can collect its reviewers before anyone submits it.
- An optional note describing what changed and where reviewers should look. The note opens the review cycle's discussion.
Submitting notifies the requested reviewers, along with any reviewer whose change request still blocks release. See Requesting Reviews for how requests behave across review cycles.
Reviewers can also be added while a revision is in review, from the reviews panel below the steps, where each requested reviewer carries their own actions. See Requesting Reviews.
Reviews
The reviews panel sits below the procedure's steps, whatever the revision's status. Its header bar stays on screen: while the discussion is still below the fold it rides the bottom of the window, and once you scroll to it the bar pins to the top while you read. Either way it states whether the revision is ready to release. The panel shows who was asked to review and whether they have, along with the discussion grouped by review cycle. The steps above scroll within their own card, so the reviews are always a short scroll away. Beside the procedure title, a summary shows approval progress at a glance and jumps to the panel.
To review, write an optional explanation, choose an outcome, and select Submit:
- Comment joins the discussion without affecting release.
- Approve counts toward the review policy.
- Request changes blocks release until that reviewer approves or an administrator dismisses the request.
You can comment whatever the revision's status. Approve and Request changes require the revision to be In review, and only approvals and change requests from users with the Approve procedure permission affect release. An outcome you cannot submit is shown disabled and says why. See Reviews and Approvals for the complete rules.
A review may include a written explanation that mentions other users. Comments can be edited or deleted by their author until the revision is released or archived; an approval or change request explanation is fixed once its cycle closes.
The Release action is in the status section of the side panel, which also holds the revision's owner, tags, part, and version. The reviews panel repeats neither, so there is one place to act on the revision's status. Until the revision is ready, the disabled Release action states what it is still waiting on, and the reviews panel header says the same thing.
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 revision becomes ready to release, Factorial notifies the procedure owner.
Revision History
The details of a revision include its version number and a link to the previous released revision in the same lineage, so reviewers can open the process the revision replaces.
Activity
The procedure activity feed displays changes to the procedure over time. It includes review events, comments, and state changes.
Revision Diffs
Every revision after the first can be compared with the newest revision released before it, which is the release it replaces. A new draft revision can be created from any revision that was released, including an older one, for example to roll back a change. A draft created from an older release is still compared with the release it replaces, so the comparison shows what the rollback undoes. The page also names the revision the draft was created from. A procedure has one draft at a time: while a revision is in draft or in review, New Draft Revision is shown disabled on the other revisions and links to that draft. A draft that is archived without being released cannot start a new draft. It keeps its version number, so the next draft takes the number after it. A new draft always takes the next unused version number, whichever revision it was created from. Select Changes at the top of the procedure to open the comparison. On a first revision, Changes is shown disabled and explains that there is nothing to compare.
A new revision keeps the title of the revision it was created from. Lists show the version number next to the title to tell revisions apart.
The comparison covers everything a reviewer approves:
- The procedure's title, description, output part, and tags
- Each step's title, description, and definition blocks
- Each step's estimated duration, blocking dependencies, and default queue
- Which revision of each embedded procedure is used
Files in inline PDF and file gallery blocks are listed with their size and upload time. A file replaced by another file with the same name is therefore marked as changed.
Each step is compared with the matching step in the other revision: the two steps match when they were copied from the same step, however many revisions ago. A step is marked Changed, Added, Removed, or Moved. A step that moved and also changed is marked Moved and changed. Because a step's blocking dependencies are listed by title, renaming a step also marks every step it blocks as changed.
The page shows only what changed. Select Show unchanged to read the complete procedure with the changes in context. Two views are available:
- Formatted shows the rendered instructions, with removed content struck through and added content highlighted.
- Markdown shows the Markdown source line by line, with the changed words marked. It also shows changes that do not affect the rendered result, such as a change in formatting.
Step Changes
A single step can also be compared on its own, one definition block at a time. Select Changes at the top of a step, Step changes beside the step in the procedure comparison, or Changes in the step's Markdown preview. The step is compared with its matching step in the release the procedure replaces. A step added in this revision shows every block as added.
A block is matched with the block it was copied from when the revision was created, however many revisions ago, so a block that moved is marked Moved rather than removed and added. The step's title, description, and details, such as its estimated duration and blocking dependencies, are compared as Step details.
The Blocks menu filters the comparison by kind of block, such as documents, part requirements, and file galleries. Every kind is selected when the page opens. Clear a kind to hide its blocks, for example to review only the part requirement blocks of a step with long instructions. Part requirements that are not in a block are compared with the step details. Show unchanged and the Formatted and Markdown views work as they do for the whole procedure.
Comparisons remain available after release, so the history of a procedure can be read one revision at a time.
Releasing a Procedure Revision
A procedure revision can be released once it is ready to release. Factorial does not allow a revision to be released before its review policy is satisfied.
A released revision becomes the default for new work orders created from that procedure. When a work order is created, the procedure picker lists only the newest released revision of each procedure, with its version number. Releasing a revision does not modify existing work orders, but prompts the user with a UI to control the rollout via redlining.
Releasing a new revision does not change the status of the revisions released before it. A revision that was released stays released: work orders were built from it, and its history remains part of the record even after a newer revision takes its place as the default. Factorial does not yet show the period during which each released revision was the default. An Effective date for each released revision is planned.
Revision Rollout
Revision rollout is planned. The rest of this section describes how it is expected to work.
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.
Removing an Embedded Procedure
Removing an embedded procedure from its parent removes the reference, not the procedure. The embedded procedure keeps its steps, part requirements, and revision history, and it remains available to every other procedure that embeds it. Factorial does not allow procedures to be deleted, so a procedure that is no longer needed anywhere should be archived instead.
Dependencies are scoped to the parent procedure. Removing the item therefore also removes the dependency links that connected it to other items in that parent. Dependencies defined inside the embedded procedure are unaffected, which is what allows the same procedure to be embedded elsewhere without rebuilding its dependency graph.
An embedded procedure may be removed only while the parent procedure revision is a draft. Once a nested work order has been instantiated from the item, the item cannot be removed, because execution data is already attached to it.
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.