Conditional workflow branching on case flags

The procedure is not a single linear path — three boolean flags on cases reshape it. getFilteredTransitions (workflow-config.ts) prunes the allowed transitions:

• has_preliminary_inquiry — at INTAKE:
  • true → must go through PRELIMINARY_INQUIRY (direct CHARGES_ISSUED removed)
  • false → straight to CHARGES_ISSUED (PRELIMINARY_INQUIRY removed)
• dismissal_intent AND employee_rep_or_union_related — at EVIDENCE_PHASE: determines whether BODIES_OPINION is inserted before FINAL_REPORT (mandatory consultation).
• dismissal_intent alone also gates the witness cap.

So the legal correctness of an entire process hinges on these three DB booleans being set correctly at intake, in NewCase. There is no UI validation that they are mutually consistent, and no server enforcement — they're plain columns any client can write.

The flags interact:

has_preliminary_inquiry	dismissal_intent	employee_rep_or_union_related	Path
false	—	—	INTAKE → CHARGES_ISSUED (skip inquiry)
true	—	—	INTAKE → PRELIMINARY_INQUIRY → …
—	true	true	… EVIDENCE_PHASE → BODIES_OPINION → FINAL_REPORT
—	else	—	… EVIDENCE_PHASE → FINAL_REPORT (skip consultation)

What to verify / danger

Whether a preliminary inquiry is optional or mandatory, and exactly which employees trigger the CT/Sindicato consultation, are legal determinations reduced here to free booleans. A wrong flag silently produces a procedurally defective process. Confirm the rules and who is allowed to set/change the flags (and whether changing them mid-process should be possible at all).

Rebuild implication

Derive branch conditions from validated, well-modelled case facts; make the flags server-owned and audited; and encode the branch table in tests.

Related

• Mandatory consultation (CT/Sindicato)
• Witness limits
• The workflow engine