Problem

A customer using parallel group approvals wants to update a custom field with each group's name as it gets approved/rejected (e.g. append the group name to a multi-select field on approval, and to another field on rejection). The current STEP_DECISIONwebhook can't support this:

• It has no group identity (no groupId / group name), so the consumer can't tell which group a decision belongs to.

• It has no step status, and it fires on every individual member vote — so the consumer can't distinguish "a member voted" from "the group is resolved". VOTE behaves the same way.

Solution

Add fields to WebhookStepDecisionMessage, populated per step type in WebhookService. All values are derived from the ApprovalStep already passed into the webhook call — no extra API or DB calls.

• stepStatus (all types) — active / success / fail. Sourced from step.getStatus(), which at webhook time already reflects the post-resolution status. For GROUP it is success/fail once the approve/reject threshold is reached, active on every prior member vote.

• stepName (all types) — from step.getDisplayName():

  • GROUP / VOTE → group name

  • USER → user display name

  • EMAIL → email (with full name if available)

  • AUTOMATION / HTTP → a constant type token ("Automation" / "Http"); it does not distinguish multiple steps of the same type.

• groupId — GROUP and VOTE only (step.getGroupId()).

• decidedBy — already present; carries the accountId of the user who decided (the delegate when delegated). No change.

Example (GROUP)

{  "stepType": "group",  "decision": "accepted",                            // this member's vote, not the group outcome  "decidedBy": "5b10a2844c20165700ede21g",  "comment": "Looks good to me",  "stepName": "Finance Team",                        // NEW  "groupId": "ari:cloud:identity::group/8f0e...c2",  // NEW  "stepStatus": "active"                             // NEW - "success"/"fail" once the group resolves}

Acceptance criteria

• GROUP webhook includes groupId, stepName, stepStatus; stepStatus becomes success/fail once the threshold is reached, and is active on each member vote before that.

• VOTE includes groupId and stepStatus (active while members vote, success/fail on the moderator's decision).

• AUTOMATION / HTTP include stepName (constant type token, see note above).

• The consumer can filter in-progress events via stepStatus != active.

Out of scope / notes

• Skipped steps emit no event. Steps that end up SKIPPED do not fire a STEP_DECISION webhook. In parallel CUSTOM mode, when the group threshold is met early the remaining groups are skipped silently — the consumer receives no event for them. (Emitting webhooks for skipped steps would be a separate, larger change.)

• No custom-field write. This task only enriches the webhook payload. Updating the Jira custom field is the consumer's responsibility (e.g. Jira Automation triggered by the incoming webhook) and should be idempotent to tolerate retries/duplicates.

Alternative considered

Instead of adding stepStatus to STEP_DECISION and making the consumer skip the intermediate (active) events, we could add a separate event type (e.g. STEP_RESOLVED) sent only when a step is finally resolved. That would be simpler for the consumer. The chosen approach (enriching the existing event + filtering) is more backward-compatible and requires less code.

Implementation note (to verify during dev)

• Confirm groupId is populated for groups defined via an issue field, and for non-group poll-type VOTE steps; handle the absent case gracefully.