The engine's only "guestbook": one approval comment per row, append-only. After the task row completes and is migrated into the history tables, comments remain queryable and appendable in place — the audit trail is an independent timeline that does not move with the task.
wf_task.comment stores only the conclusive comment from the last handling action, snapshotted into wf_hi_task when the task is archived. But a task's lifecycle often involves more than one comment: every countersign participant leaves one, add-signed approvers need to state their position too, and a reject-and-redo round adds another pass — this is a continuously appended timeline that a single field cannot hold.
So comments live in their own table: one comment per row — who (user_id / user_name), when (created_at), and what was said (content), attached by task_id. Append-only: historical comments are never overwritten by later handling.
Still Readable and Writable After the Task Is Archived
Once runtime-table data completes, it migrates wholesale into wf_hi_*, whereas wf_task_comment is a persistent table: task_id is only a logical association — the task row moves away, the comments stay where they are. Completed-task detail views read it as usual, and adding a comment after the fact is no problem. To view a whole process's approval trail, pull everything at once via process_instance_id.
-- All comments of a task (chronological order)SELECT user_name, content, created_atFROM wf_task_commentWHERE task_id = '...'ORDER BY created_at;-- The complete approval comment stream of a process instanceSELECT task_id, user_name, content, created_atFROM wf_task_commentWHERE process_instance_id = '...'ORDER BY created_at;
wf_task_comment Task Comments
Table Structure
idtask_idwf_task.id(still commentable/queryable after the task is archived)process_instance_idtenant_iduser_iduser_namecontentcreated_atIndexes:
task_id,tenant_id.Why Comments Don't Live on the Task Row
wf_task.commentstores only the conclusive comment from the last handling action, snapshotted intowf_hi_taskwhen the task is archived. But a task's lifecycle often involves more than one comment: every countersign participant leaves one, add-signed approvers need to state their position too, and a reject-and-redo round adds another pass — this is a continuously appended timeline that a single field cannot hold.So comments live in their own table: one comment per row — who (
user_id/user_name), when (created_at), and what was said (content), attached bytask_id. Append-only: historical comments are never overwritten by later handling.Still Readable and Writable After the Task Is Archived
Once runtime-table data completes, it migrates wholesale into
wf_hi_*, whereaswf_task_commentis a persistent table:task_idis only a logical association — the task row moves away, the comments stay where they are. Completed-task detail views read it as usual, and adding a comment after the fact is no problem. To view a whole process's approval trail, pull everything at once viaprocess_instance_id.Usage Examples
Back to the Data Model Overview