thinkwise-software-factory-process-flows

Stage a process_flow row with model_id, branch_id, and process_flow_id, then add process_action rows, connect them with process_step rows, and add process_variable rows if data passes between actions. There is no dedicated create task; the flow is added directly via stage_resource.

Only eight types are observed as starting points: activate_detail, open_document, add_record, edit_record, delete_record, execute_tab_task, execute_task, and execute_system_task. The trigger object must be modeled as its own eligible action wired directly after the start node.

A flow becomes a system flow automatically when every process_action in it is a non-interactive type; the is_system_flow field is computed and cannot be set directly. Roughly 57 of the 100 action types, including connectors, decision, and file operations, are system-flow eligible.

Setting process_action_type, tab_id, or task_id can overwrite process_action_id with an auto-suggested value, and batched writes can silently reset fields. Order process_action_id last in a single combined write and verify the returned fields block before continuing.

Avoid a process flow when a single task, subroutine, or Default/Layout/Context control procedure already covers the sequential logic. Flows are justified only when coordinating multiple distinct actions whose order or outcome is meaningful, such as integrations, approvals, or scheduled batch work.

Add a process_flow_schedule row under the flow with a schedule_id and recurrence settings, such as occur_once for a fixed daily time. Scheduling only works meaningfully once every action in the flow is non-interactive, making it a true system flow.