Recommended patterns

Order numbers below are examples; arrows are on-success routes unless noted.

1. Small team: plan, build, review, you merge. 1 Plan (Engineering Lead) → 2 Implement (auto) → 3 Code review (Code Reviewer; failure → 2) → 4 Human merge (human gate, Merge gate; failure → 2) → 5 Done. Needs a lead, at least one implementer and a code reviewer. With no lead, drop Plan and set Implement to a fixed role (for example backend-engineer or fullstack-engineer).

2. QA done by a person. 1 Plan → 2 Implement (auto) → 3 Code review (failure → 2) → 4 Human merge (failure → 2) → 5 QA (Human gate, action QA, owner: your tester, backup: a second tester; failure → 2) → 6 Done. The tester is messaged when the merge lands and passes or sends back from Slack or the portal.

3. Security review before merge. 1 Plan → 2 Implement (auto) → 3 CI / quality (DevOps; failure → 2) → 4 Code review (failure → 2) → 5 Security review (Security Engineer; failure → 2; skip → 6) → 6 Human merge (failure → 2) → 7 QA (failure → 2) → 8 Done. Security skips itself on changes with no security surface.

4. Docs-only or writing work. 1 Write (Custom step, fixed role docs-engineer, with your brief, e.g. "Update the API docs for the new endpoints and open a PR", or "Write the runbook for X and publish it to Confluence") → 2 Sign-off (Human gate; owner: the doc's reviewer; failure → 1) → 3 Done. (The built-in Docs action is designed to run after a merged change, looking for docs the change made out of date.)

5. Regulated team: two human approvals. 1 Spec (Product Analyst) → 2 Scope sign-off (Human gate, Sign-off; owner: product lead; failure → 1) → 3 Plan → 4 Implement (auto) → 5 CI / quality (failure → 4) → 6 Code review (Human gate, action Review; owner: senior engineer, backup: another; failure → 4) → 7 Security review (failure → 4; skip → 8) → 8 Human merge (owner: release manager; failure → 4) → 9 QA (failure → 4) → 10 Done. Approving the PR on the code host passes step 6; requesting changes sends it back with your review.

6. Fullstack-first team. Default workflow, with Implement's Who gets the work set to Fullstack engineer for backend, frontend and spanning work. One engineer, one PR per repo, even when you also have specialists. Keep the specialists' defaults if you want them to take single-discipline work.

Tips:

• Give every human step an owner, or someone must remember to check Deliveries.
• Set human steps' On failure → to Implement so Send back means rework.
• Turn on Jira for Implement and Done so the issue tracks the delivery.
• Use Duplicate to try changes on a workflow that has deliveries in flight.