Problem

The step chooser offers seven ways to add an approver, but there are only three kinds of approver: a user, a group and an email address. Each of them appears twice, once for a value chosen in the definition and once for a value taken from a work item field.

What it costs:

1. The administrator has to decide where the approver comes from before configuring anything else. When it turns out later that the approver should come from a field rather than be named in the definition, the only way out is to delete the step and build it again. The action type, comment requirements, watcher notifications, conditions and exclusions are all lost.

2. The chooser is twice as long as the number of decisions actually being made, and two cards for the same kind of approver read as two different features.

3. The two variants of the same approver kind have quietly drifted apart, each offering options the other does not. Nobody notices, because they are never seen side by side.

Proposed solution

The chooser offers one card per approver kind: User, Group and Email, next to Vote, Automation, Webhook and AI Prompt as today. Where the approver comes from becomes a choice inside the step instead of a choice of step.

Each of the three forms opens with a Source choice:

In Confluence there are no work item fields, so no choice is offered and the step works as it does today.

Nothing an administrator can configure today disappears, and nothing new appears. Each of the six combinations keeps exactly the options it has now. The Source choice only decides which of them the form shows.

Changing the source

Everything that means the same thing on both sides keeps the value the administrator gave it: the action type, comment requirements, watcher notifications and conditions, and for Group also the voting thresholds and the exclusions.

Everything that exists on one side only goes back to its default, starting with the approver itself. A step is therefore never saved with something that was configured for the other source. Before anything already filled in is discarded, the administrator is warned.

What stays the same

• definitions built before this change open with the correct source preselected and every option filled in as it was saved

• steps look the same in the definition list, in the step header and in the approval view, including their icons

• approvals already running are unaffected, and so are exported definitions, definition templates and the API

Acceptance criteria

1. The approval step chooser lists one card per approver kind, with no separate "Work item field - ..." cards.

2. The User, Group and Email steps let the administrator choose between a value and a work item field in Jira, and offer no such choice in Confluence.

3. Choosing the work item field source replaces the value control with a field picker and shows the options belonging to that source.

4. Every combination of step and source offers exactly the options it offers today: none added, none removed.

5. Changing the source keeps the action type, comment requirements, watcher notifications and conditions, and for Group also the voting thresholds and the exclusions.

6. Changing the source clears the approver and every option that belongs only to the source being left, and the administrator is warned before anything filled in is discarded.

7. Changing the source twice does not bring back a cleared value.

8. A step saved before this change opens with the correct source preselected and every saved option in place.

9. The definition list, the step header and the approval view show the same icons and labels as before the change.

10. Running approvals, exported and imported definitions, definition templates and the API keep working with steps saved before this change.

Out of scope

• how approvers are resolved while an approval runs