Why

An approver must open a work item or a page today to learn that something waits for them, to understand why an approval is stuck, and to submit a decision. Rovo chat is becoming the place where Cloud users ask "what needs my attention".

This epic brings approvals into that surface, in both products, as a thin conversational layer over the approval engine we already have. No new domain logic: reads reuse the approvals list and approval path services, the decision reuses the same headless step-action path that e-mail action links already use.

Phases

Phase 1

Read plus a single decision. List what waits for my decision, report all approvals running on a work item or page, explain what blocks an approval, and submit approve / reject / abstain / consent with a confirmation, honouring every rule the product already enforces.

Phase 1 also makes those actions selectable in agents customers build themselves (read:chat:rovo), with reads open and a decision behind an administrator switch. This cannot be deferred: Rovo registers an app's actions only when the app ships its own agent, so the exposure and the bundled agent land together.

Phase 2

• searchApprovals with analytics, using the same filters as the approvals list in the app

• bulk decision over my pending approvals, with a per-item audit record

• vote steps (submitting a vote with option selection, moderator role)

• startApproval from a chosen definition

• remaining-path preview: which steps are left and who will be asked

Constraints that apply to the whole epic

• Rovo is available on paid Cloud plans only, so this is a convenience surface for licensed users. JSM portal customers and external e-mail approvers keep working exactly as today, and this epic does not change those paths.

• Rovo chat renders text only. There are no approval buttons in chat; a decision is a conversational action with a confirmation step.

• Everything an action returns is processed by Atlassian's LLM. Data minimisation and an administrator switch are therefore hard requirements, not enhancements.

• Every action must be gated on an active app licence and must compute permissions server-side, because approval data is not protected by Jira or Confluence permissions on its own.

• Our agent's prompt is not a security boundary. Once the actions are selectable in customer-built agents, every rule must hold in the backend regardless of the caller.