Factorial Docs

Appearance

Projects ​

  Table of Contents

A project is a one-off execution that does not require a released procedure. Projects are useful for prototypes, experimental builds, corrective work, and other tasks whose process must develop while the work is underway.

Unlike a work order, a project can begin without completing the procedure review and release process. Use a procedure and work order when the process is repeatable and requires revision-controlled instructions.

Projects are both editable like a procedure and actionable like a work order. A project task's step is edited and recorded on the same page, so blocks like data fields and part requirements can be added while the task is underway.

The projects list hides completed and canceled projects. Turn on Show completed or Show canceled to include them. Filtering the list by status shows the selected statuses regardless of these toggles, and filtering by who completed or canceled a project shows those projects. When the list is empty, it says what the toggles are hiding.

Permissions ​

Projects allow work to proceed without an approved procedure, so access is controlled by dedicated permissions. An organization can limit who may create or execute projects or disable projects entirely.

Defining and Executing Project Work ​

A project combines process definition and execution in one place. It supports the same kinds of definition blocks used by procedure steps, along with comments, task ownership, queues, scheduling, timeline planning, and a Kanban view.

This allows a team to add or refine work as a prototype develops while retaining an execution record of the tasks performed.

Recording Values on Project Tasks ​

Each project task is its own definition: its step is edited on the task page, in the same place the task records its values. A project task has no review, no release, and no frozen copy, so a change to the step takes effect on the task immediately.

  • Data fields show their input on the block, with the block's Required toggle and Change field beneath it.
  • Data tables are a single grid. Columns are edited on the step, and rows and values are recorded on the task. A project task always adds and deletes its own rows, so a project table has no operator access setting and no initial rows. A required column asks for a value in each row the task adds, so a table with no rows asks for nothing.
  • Part requirements are defined on the step like on a procedure step. Projects have no output inventory, so their requirements cannot be installed.

Values follow the same rules as on a work order task. Recording a value starts the task, a held task or one with unfinished dependencies cannot record values, and each change appears in the task's history. A completed or canceled task shows its values read-only until it is reopened, and its step's blocks cannot be edited until then either, nor can the blocks of a completed or canceled project's tasks. The task's title and description stay editable, since they don't change what it recorded. A held or blocked task can still change its table's columns.

A task with an incomplete required field cannot be marked as completed. A project cannot be completed while any of its open tasks is missing a required field, because a completed project's tasks can no longer record values.

Because the step and the task change together, an edit to the step can remove values the task already recorded. Removing a data field or data table block, changing a block's or a column's field, and removing a column each clear the affected values. Factorial asks for confirmation first, and the task's history records each change with who made it: a cleared value shows its old value, and a removed data table shows which rows went, while the earlier entries of that table keep the values recorded in it. Toggling whether a field is required keeps its value.

Comments ​

Each project task has its own comments section. The project page shows a conversation that combines comments on the project itself with comments on its tasks, in the order they were written. Each task comment links to its task, so a reader can follow the whole project in one place and open the task for detail.

A comment posted on the project page belongs to the project as a whole, such as kickoff notes or a weekly status. Comments on a sub-project stay with that sub-project. Mentioning a user with @ sends that person a notification that opens the conversation.

Reusing Released Procedures ​

A project may embed a released procedure when part of the work already has a controlled process. The embedded work uses the released procedure while the surrounding project remains flexible.

Converting a Project to a Procedure ​

Select the conversion action on the project overview to create a draft procedure from the project. The resulting draft follows the standard review and approval process before it can become the default for new work orders.