Working with Jira issues
This is the feature the app exists for. Mitigation work usually already lives in Jira; connecting the plan to it means the risk register stops being a separate description of the same work.
The three modes
| Mode | Use when | Jira footprint |
|---|---|---|
| Plugin only | The work is small, or the team does not use Jira for it. | None. Actions live in the app. |
| Link an existing epic | The work is already planned and tracked in Jira. | The plan attaches to that epic. |
| Create a new epic | The work is new and should be delivered by a Jira team. | The app creates the epic and its issues. |
What synchronises
Two independent switches control synchronisation:
- Status — when the Jira issue moves, the action’s status follows.
- Assignee — the Jira assignee and the action owner stay aligned.
You can enable either, both, or neither.
Sync is one-way in this release. Changes flow from Jira into the treatment plan, not back. Two-way synchronisation of status and assignee creates conflicts and update loops in real installations, so it will arrive behind a flag with a reconciliation job rather than being switched on by default. Plan your process around Jira being the source of truth for delivery state.
Linking work items to an action
Within a plan you can also link individual Jira work items to individual actions, rather than linking the whole plan to one epic. Use Link work item on the action.
This is the right approach when a plan spans several teams and several boards, and no single epic covers it.
What happens if the Jira issue is deleted
The action remains and its link is marked broken. Nothing in the treatment plan is deleted, because the risk record must survive changes to the delivery tooling.