Overview
This domain has 2 tables: workflow stores the current workflow definition as JSONB in the
definition column, along with compiled reference data in compiled_refs, and
workflow_version stores a snapshot of the definition on every change so earlier versions can
be inspected or restored
Table workflow
| Column | Type | Nullable | Default | Description |
|---|
id | SERIAL | NO | nextval(...) | Primary key |
name | VARCHAR(255) | NO | - | Workflow name |
description | TEXT | YES | - | Workflow description |
status | VARCHAR(20) | NO | 'draft' | Workflow status |
definition | JSONB | NO | - | Full workflow definition (nodes and connections) |
compiled_refs | JSONB | YES | - | References compiled from the definition for runtime use |
line_oa_id | INTEGER | NO | - | LINE OA the workflow belongs to |
organization_id | INTEGER | NO | - | Organization that owns the workflow |
created_by | INTEGER | YES | - | Creator (user id) |
updated_by | INTEGER | YES | - | Last updater (user id) |
created_date | TIMESTAMPTZ(3) | NO | now() | Creation timestamp |
updated_date | TIMESTAMPTZ(3) | YES | - | Last update timestamp |
deleted_date | TIMESTAMPTZ(3) | YES | - | Deletion timestamp (soft delete) |
Table workflow_version
| Column | Type | Nullable | Default | Description |
|---|
id | SERIAL | NO | nextval(...) | Primary key |
workflow_id | INTEGER | NO | - | Workflow this snapshot belongs to (FK to workflow.id) |
version | INTEGER | NO | - | Snapshot version number |
definition | JSONB | NO | - | Snapshot of the workflow definition at that version |
event | VARCHAR(20) | NO | - | Event that produced this version |
created_by | INTEGER | YES | - | User who produced this version (user id) |
created_date | TIMESTAMPTZ(3) | NO | now() | Timestamp the version was recorded |
Notes
workflow_version.workflow_id is a FK to workflow.id, with an index on
(workflow_id, version DESC) so the latest version can be fetched quicklyworkflow is indexed on (line_oa_id, organization_id) for per-tenant queries and on
deleted_date for filtering soft-deleted rowstrigger_rule references workflow.id through trigger_rule.workflow_id and pins the node
it belongs to via workflow_node_path (see Trigger Rules and Scheduled Jobs)scheduled_action also carries workflow_id and workflow_node_path, so a scheduled action
can be traced back to the workflow node that created it- There is no schema-level unique constraint on (
workflow_id, version) — version uniqueness
is enforced by the application