Context

Reviewing archived approvals already works: the Status = Archived filter on the Approvals page and GET /webapi/v2/approvals?status=ARCHIVED. Restoring does not exist anywhere in the app, for any object.

Archiving does not change the state of an approval (status, steps and decisions already made are left untouched), so restoring is resuming the process in place, not recreating data.

Scope

1. An Unarchive action in the UI, available on archived approvals, in Jira and in Confluence: a row action on the Approvals list and an "Unarchive approval" button in the approval panel (work item or page panel, Details view). Each action asks for confirmation.

2. A PATCH /webapi/v2/approvals/{approvalId}/unarchive endpoint with its own API key privilege "Unarchive".

3. Re-sending notifications to the approvers of steps waiting for a decision.

Assumptions

Resume, not restart. The approval returns to its pre-archive state: same identifier, same definition, same steps, all decisions made earlier preserved. The process continues from where it stopped. Completed approvals keep their status and resolution date.

Restoring creates a new version of the approval. This keeps the pre-archive state in history and makes old notifications (Slack buttons, decision links in emails) stop working. Nobody approves the approval by clicking a link from an email sent before archiving.

New notifications. Approvers of steps waiting for a decision receive fresh notifications through the normal notification routing (current notification settings), the same way as when a step starts. Nothing is sent when the approval can no longer be decided (completed or expired).

• Group steps skip members who already decided, and their delegates.

• A vote step whose voting closed while archived, or where every member already voted, calls the moderator instead of the voters.

• Slack messages sent before archiving stay in their "archived" state and are not updated.

All features come back. Once restored, the approval again accepts decisions, counts towards workflow conditions and validators, is visible in the Jira field and in JQL, returns to the approvers' pending lists, delegations and dashboard statistics. Automatic reminders count the restore as the last action, so they resume one interval after restoring.

Decision deadline and validity expiration are shifted. A date that passed while the approval was archived is recalculated from the moment of restoring, so the restored approval does not expire immediately. Dates that did not pass are kept.

• Decision deadline: the original period from the approval start to the deadline, set from the restore.

• Validity expiration: the original period from the approval date (resolution) to the expiration, set from the restore; the start is used when the approval date is unknown, so validity is never longer than the approval had.

Trace in history. Every restore is recorded with who restored the approval, when, and which version it created.

• Activity (panel and Activity page) shows a "Restored" row: the restorer in the Step column, the version and the date. The CSV export shows the decision "Restored". Filters on steps hide restore rows.

• The approval panel header shows "Restored from archive by <user> on <date>" for the latest restore, hidden while the approval is archived again.

Permissions. The UI action requires the same permission as archiving (in Confluence "Archive existing Approval Path", whose tooltip now says it also allows unarchiving). The API uses a separate key privilege, shown as a new "Unarchive" column in the API key form and "UA" in the key list. With "Allow change performer origin" the performer needs the same access as for archiving.

API behaviour. The endpoint returns the restored approval. It returns 200 without changes when the approval is not archived, 404 when it does not exist, 403 without the privilege and 409 when the approval changed concurrently.

Confluence page changes. For an approval that approves the current page version, a page whose content changed while the approval was archived gets the normal page-change handling on restore: the approval is marked outdated and restarted when the definition says so, only where a live page edit would do the same (validity not expired, decision deadline not passed after the shift). The user sees the outcome as a warning. A page that cannot be read is treated as unchanged.

Out of scope

• Unarchive in Jira Automation and in the workflow post-function. Archiving is available there; restoring is a corrective operation performed deliberately by a person or an integration.

• Restoring deleted approvals.

• Recreating the interactive Slack messages from before archiving.

• A webhook for archiving and restoring (webhooks currently cover creation, step decision and completion only).

• Bulk restoring.

Fixes included

1. AI prompt step results survive a new version. Creating a new version (reassignment, dynamic field update, restore) gives steps new ids and lost the stored prompt execution of each prompt step; the latest execution is now copied to the new step.

2. Web API v2 returns resolutionDate for finished approvals. The field was documented but always empty; it now holds the date an Approved or Rejected approval reached its outcome. The same date now also reaches Rovo approval search as the completion date.

3. Archiving and unarchiving update the approval's Modified date (Approvals list column, CSV export, Modified filter and sorting, My overview).

4. A decision link from before the approval was updated to a new version says: This link is no longer valid because the approval was updated to a new version.

Acceptance criteria

• An archived approval offers an Unarchive action in the UI, visible only to a user holding the archive permission.

• After restoring, the approval disappears from the Archived filter and returns to its previous status (Ongoing / Approved / Rejected).

• The approver of an active step can make a decision from the approval panel and from a new email.

• A decision link from an email sent before archiving does not work. No-login links of external approvers (AP-2530) are the exception: they follow the approver to their current step and keep working.

• An approval whose decision deadline or validity expiration passed during archiving has its date shifted by the original period after restoring, and does not expire immediately.

• The workflow condition and validator, the Jira field and JQL search all see the restored approval.

• The approval returns to the approver's pending list and to delegations.

• Automatic reminders resume.

• Archiving a restored approval again works.

• PATCH /webapi/v2/approvals/{approvalId}/unarchive works for a key with the matching privilege and returns 403 without it.

• The Activity view and the approval panel show who restored the approval and when.

• The OpenAPI description covers the new endpoint and privilege.

Manual tester notes

• Panel (Jira and Confluence): archive an in-progress approval, add Archived to the panel's Status filter, click "Unarchive approval" and confirm. The approval is in progress again as a new version, the header shows "Restored from archive by", the approver gets a new notification on each configured channel, and deciding from the panel works. The decision link from the email sent before archiving and the old Slack buttons no longer work. A no-login link of an external approver keeps working and opens their current step.

• Approvals list: filter Status = Archived, use the Unarchive row action on an Approved and on a Rejected approval. Status and resolution date are unchanged, the Archived badge is gone, archiving and unarchiving again works, each restore adds a version.

• Activity page and panel Activity tab: one "Restored" row per restore with the restorer, version and date; the CSV export shows "Restored"; filtering by step type or step status hides these rows.

• Group step where some members decided before archiving: only members who have not decided (and their delegates) are notified again. Vote step whose voting deadline passed while archived: the moderator is asked to decide.

• Decision deadline: start an approval with a short decision deadline, archive it, wait until the deadline passes, unarchive. It does not expire, and the new deadline equals the restore time plus the original period. Same for validity on an Approved approval with a short validity period.

• Automatic reminders: on a definition with reminders, archive for longer than three intervals, unarchive; reminders arrive again one interval later.

• Jira: the approval JQL clause, the Jira field and the workflow condition or validator see the restored approval again (an Approved approval lets the transition through after restoring).

• Pending lists: the restored approval is back in My overview and in the delegate's view.

• Permissions: a user without the archive permission sees no Unarchive action; in Confluence, check the tooltip of "Archive existing Approval Path".

• Two people unarchiving the same approval at the same time: the second gets a message that the approval is no longer archived.

• API keys: the form shows the Unarchive column with a New badge, the key list shows UA. The endpoint returns 403 without the privilege, 200 with it (and 200 again on a repeat), 404 for an unknown id.

• Web API: GET /webapi/v2/approvals/{approvalId} returns resolutionDate for an Approved or Rejected approval and leaves it empty for an Ongoing one.

• Confluence "approve current page version": edit the page while the approval is archived, then unarchive. The approval becomes outdated (and restarts when the definition restarts on page changes) and a warning explains it. Without a page edit it resumes normally.

Known limitations

• An AI prompt step still running when the approval is restored loses that run's result (the new version has new step ids); the stuck-step check fails it and it can be run again, as after a reassignment today.

• A vote step where some members have not voted re-notifies all voters while voting is open, including those who already voted.

• A Confluence page edit made while the restore is being saved is not seen as a change; the next page edit outdates the approval.

• Every restore re-notifies approvers and adds a version; nothing limits repeated archive and unarchive. Skipping the notification is not an option because the restore invalidates the old email links and Slack buttons.