## TL;DR
Jira transitions move issues between statuses, and each status allows only its own outgoing transitions. 'Not available' means the transition id doesn't exist on the path from the issue's current status: wrong id, the issue moved already, or the workflow changed. Fetch the issue's available transitions and pick from that list; never hardcode transition ids.

## The query

```text
jira api workflow transition not available
```

## Use this when

- Jira API transition calls fail as not available
- A transition works for some issues but not others
- A workflow change breaks an integration


## Not for

- Jira authentication errors
- Issue creation failures
- Permission errors on issues


## Steps

### 1. Fetch the issue's available transitions

Call the transitions endpoint for the exact issue. The response lists every transition valid from its current status, with ids. If your id isn't there, it can't run, full stop.

Expected output: the available-transitions list for the issue.

### 2. Match the transition to the current status

Compare the issue's current status against the workflow. Issues in different statuses have different transitions; an id valid from 'To Do' fails from 'In Progress'. Your code must read status first, then choose.

Expected output: the transition id confirmed valid from the issue's actual status.

### 3. Handle the issue having moved

If another agent or automation moved the issue between your read and your transition call, the id goes stale. Re-fetch transitions right before calling, and treat 'not available' as 're-read and retry'.

Expected output: a read-then-transition sequence with no stale ids.

### 4. Stop hardcoding transition ids

Look up the transition by name from the available list at runtime instead of storing ids in config. Workflow admins renumber and rename transitions; hardcoded ids break silently on every workflow edit.

Expected output: runtime lookup of transition ids by name.

## Variant phrasings

### jira transition id invalid api

Steps 1 and 4: fetch the list, then stop hardcoding.

### jira workflow transition failed

Step 3's re-read covers the moved-issue case.

## Why it happens

Workflows are per project and editable by admins, so transition ids are moving targets dressed as constants. Integrations hardcode the ids they saw once, and the first workflow tweak breaks them. The available-transitions endpoint exists precisely because ids can't be trusted across time.

## Edge cases

- Some transitions have screens or validators that the API must satisfy. 'Available' doesn't mean 'will succeed'.
- Bulk transitions need per-issue lists. One issue's transitions don't apply to another in a different status.
- Transition ids differ between Jira Cloud and Data Center. Don't port configs across hosting.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yWdysv8gdYwK5L0EgHRRFg