Workflows, workflow schemes, and transitions
A workflow is a set of statuses joined by transitions. Each transition can carry a screen (what the user fills in), a condition (who may execute it - conditions remove the button), a validator (input that must be valid - an error blocks the transition), and post functions (side effects that run after success: setting resolution, assigning, updating a field, firing events). Validators always run before post functions; that ordering is a recurring exam point.
Workflows attach to projects through a workflow scheme, which maps each issue type to a workflow and defines a default workflow for anything unmapped. Workflows and schemes can be shared across many projects, so editing an active workflow silently changes behaviour everywhere it is used. Cloud lets you edit an active workflow directly or create a draft, then publish or discard it. Statuses have categories - To Do, In Progress, Done - which drive board columns, done-ness and reports, whereas the status name itself is free text.
Traps: choosing a condition when the requirement is validation (“resolution must be set before closing” is a validator, not a condition); forgetting that an All transition lets any status move to the target; assuming a status used by a workflow can be deleted; and attaching a new workflow scheme without planning what happens to issues whose current status is missing from the new workflow.
Rule of thumb: condition = who, validator = what, post function = then.