Cabinee database schema
The diagram shows the main entities and relationships. Actual table changes are also recorded in the Liquibase changelog.
User tasks (bd_task)
A task is linked to both the parent ticket and the space:
| Column | Type | Purpose |
|---|---|---|
ticket_id | UUID | Parent ticket |
workflow_id | UUID | Task space, foreign key to bd_workflow.id |
due_date | TIMESTAMP WITH TIME ZONE | Due date, synchronized with the process engine |
completed_time | TIMESTAMP | Task completion time |
workflow_id is set when the task is created from bd_ticket.workflow_id and is not updated by the ORM afterwards. due_date can change when new task events are received from Camunda.
For existing tasks, a migration fills bd_task.workflow_id with the parent ticket’s space. Indexes idx_bd_task_workflow_id and idx_bd_task_due_date are created for Criteria API queries.
Process instance ↔ ticket mapping (Camunda 8)
Camunda 8 process instances have no business key, so the link to a ticket is stored separately — in schema camunda8_adapter, maintained by unibpm-camunda8-adapter.
| Column | Type | Purpose |
|---|---|---|
process_instance_key | VARCHAR | Numeric process-instance key in Zeebe, primary key |
business_key | VARCHAR | Ticket identifier |
parent_process_instance_key | VARCHAR | Parent instance for a call activity |
tenant_id | VARCHAR | Instance tenant |
bpmn_process_id | VARCHAR | Process identifier from BPMN |
The table is filled from VARIABLE records when the businessKey variable appears on the instance, and cleared when the instance completes or is canceled. Call-activity child instances inherit the parent’s business_key.
The schema is not managed by Liquibase: it is created by a separate init script, and the adapter’s ddl-auto remains none. This is intentional so that resetting Cabinee Liquibase changelogs does not drop the mapping table.