Workflow tutorial: safe delivery

Build and test a guarded Harbor delivery process, then publish it safely.

Goal and prerequisites

As a SAMPLE project manager, create a process that prevents work starting without acceptance criteria and prevents review completion while blockers or pending reviews remain. Use fictional tickets only. Record current workflow assignment before changing an existing process.

The tutorial uses a draft. Published configuration remains effective until a successful publication. New workflows do not automatically reassign existing tickets.

Build the stages

1. Open Workflows and create or edit the intended draft.
2. Add To do (To do category), In progress (In progress), In review (In progress), Ready for release (In progress), and Done (Done).
3. Make To do initial.
4. Connect To do → In progress → In review → Ready for release → Done. Add explicit reverse transitions where your team needs rework; reverse moves are not implied.
5. Position the stages so the primary path reads left to right. Use coordinate fields as an alternative to dragging.

Ready for release remains an In progress category here. The release policy can accept it without falsely describing post-release testing as complete.

Block an incomplete start

Select To do → In progress. Allow the intended working roles. Require Acceptance criteria and Assignee. Add All blockers resolved as a relationship condition.

Select SAMPLE-4, the fictional acceptance-criteria task with empty acceptance criteria, for simulation. Expect a blocked result identifying the missing field. Add meaningful acceptance criteria to the test ticket, assign an eligible owner, and resolve any blocker before repeating. A formatting-only heading or whitespace does not satisfy the requirement.

Try the published rule through a ticket status edit, a board move and a bulk move. The same requirements must apply in all three places.

The existing sample workflow requires acceptance on In progress → In review. These production captures demonstrate that guard with SAMPLE-4; the To do → In progress rule above is the new draft design taught by this tutorial. Simulation sample fields override saved values for the test without changing the ticket.

Add review logic

For In review → Ready for release, require Release-note text. Use a Match all group containing:

• No pending review requests.
• At least one completed review request.
• All direct children done, if this transition is intended to require finished subtasks.

For a conditional exception, nest Match any with priority Equals low and At least one completed review request, while keeping No pending review requests outside that subgroup. The result means low-priority work may lack a completed review, but outstanding requests still block.

Use the actor checks when a transition must be performed by the assignee or reporter. A manager role alone does not bypass a separate actor condition. Require Transition reason provided on a rework transition if your team needs an explanation.

Publish and migrate

Save the draft, run simulation and preview publication. If removing an occupied stage, choose the destination for its tickets. Map planned-release readiness policies that refer to removed stages too. Review affected counts and mappings before committing.

Publication atomically applies the validated workflow and ticket migration. If a ticket or relevant configuration changed after preview, publication rejects it as stale. Refresh the preview and reconsider mappings; do not repeatedly submit the old preview.

Workflow edits can affect up to 1,000 tickets in one publication. Plan larger changes in smaller supported operations. Historical live-release snapshots retain the stage/status information captured at launch.

Verify the outcome

A complete, unblocked ticket moves; an incomplete one remains in its current status with a useful explanation. Board columns still map the intended statuses. Release eligibility still matches the planned policy. History identifies the publication and changes rather than implying a deployment occurred.

Next, attach an AI refinement chain using the automation walkthroughs. Transition rules remain enforceable even when a chain proposes a move.