> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serial.okos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Processes

> An in-depth look at the structure and purpose of the `processes` table in the Serial database

## Introduction to the Processes Table

The processes table is designed to store information about manufacturing steps in a workflow. This table plays a central role in the Serial system by representing various types of processes that components go through during production.

## Table Structure

The processes table is structured to capture detailed information about each process, including its properties, relationships, and versioning. Here's a detailed breakdown of its columns:

| Column Name             | Data Type                | Constraints             | Description                                           |
| ----------------------- | ------------------------ | ----------------------- | ----------------------------------------------------- |
| id                      | uuid                     | primary key             | Unique identifier for the process                     |
| company\_id             | uuid                     | foreign key             | Reference to the company the process belongs to       |
| name                    | text                     | not null                | Name of the process                                   |
| created\_at             | timestamp with time zone | not null, default now() | Timestamp of process creation                         |
| use\_api                | boolean                  | not null, default false | Indicates if the process uses an API                  |
| record\_operator        | boolean                  | not null, default false | Indicates if operator information should be recorded  |
| is\_mandatory           | boolean                  | not null, default true  | Indicates if the process is mandatory                 |
| break\_prior\_links     | boolean                  | not null, default true  | Indicates if prior links should be broken             |
| dependent\_process\_ids | uuid\[]                  | not null, default '{}'  | Array of process IDs that this process depends on     |
| type                    | text                     | not null                | Type of the process (e.g., PRODUCTION, INSTANTIATION) |
| revision                | bigint                   | not null, default 1     | Revision number of the process                        |
| carbon\_copy            | jsonb                    |                         | JSON data for process carbon copy                     |
| revision\_description   | text                     | default ''              | Description of the revision                           |
| created\_by\_user\_id   | uuid                     | foreign key             | Reference to the user who created the process         |
| allow\_batch            | boolean                  | not null, default false | Indicates if batch processing is allowed              |
| approved                | boolean                  | default false           | Indicates if the process is approved                  |
| approved\_by\_user\_id  | uuid                     | foreign key             | Reference to the user who approved the process        |
| approved\_at            | timestamp with time zone |                         | Timestamp of process approval                         |
| show\_media\_numbering  | boolean                  | default false           | Indicates if media numbering should be shown          |

## Usage and Functionality

The processes table is designed to be versatile and support various aspects of manufacturing workflow management. Here are some key points about its usage:

1. **Process Versioning**: The table supports versioning through the `revision` column, allowing multiple versions of a process to be stored and tracked over time.

2. **Approval Workflow**: With the `approved`, `approved_by_user_id`, and `approved_at` columns, the table implements an approval system for processes, ensuring quality control and proper authorization.

3. **Process Dependencies**: The `dependent_process_ids` column allows for the creation of complex workflows by defining dependencies between processes.

4. **Process Types**: The `type` column supports different types of processes, as defined in the ProcessType enum:

   ```typescript
   export enum ProcessType {
     Production = "PRODUCTION",
     Instantiation = "INSTANTIATION",
     AssignWorkOrder = "ASSIGN_WORK_ORDER",
     Repair = "REPAIR",
     Field = "FIELD",
     Property = "PROPERTY",
   }
   ```

5. **Company Association**: Each process is associated with a company through the `company_id` foreign key, allowing for multi-tenant support in the application.

## Notes

* The `carbon_copy` column stores JSON data, which can be used to keep a snapshot of the process configuration for historical purposes.

* The `show_media_numbering` column suggests that processes can involve media elements, possibly for documentation or instruction purposes.

* The table is designed to work in conjunction with other tables such as `process_steps`, `fields`, and `work_instruction_blocks` to provide a complete representation of a manufacturing process.

By leveraging the processes table, the Serial application can efficiently manage and track various manufacturing steps, support complex workflows, and maintain a versioned history of process changes, all while ensuring proper authorization and company-specific data isolation.