Work with Request Resolver

Rovo Service is now Request Resolver. If you're searching for Rovo Service documentation, you're in the right place.

Request Resolver is not HIPAA compliant. You should not use Request Resolver for sites or projects that handle protected health information (PHI).

Request Resolver is an AI teammate that can help you work more efficiently in Jira Service Management by automating common tasks. You can think of it as a virtual service agent.

It reads a new request, writes a step-by-step resolution plan grounded in your runbooks, and either waits for a human to approve the plan or carries it out on its own, within the permissions you give it.

Get started with Request Resolver


This page will help you understand what Request Resolver can read, decide, and do, and what each capability needs from you to work well.

How Request Resolver works

At a high-level, this is a typical workflow for the Request Resolver:

  1. You enable Request Resolver per request type and a mode (supervised, autonomous, or off).

  2. Request Resolver reads the request and any linked internal knowledge base.

  3. Request Resolver writes a resolution plan that shows every step and cites the runbooks it used.

  4. Request Resolver delivers the plan using native Jira Service Management actions and any connected tools, pausing for human input or approvals when needed.

  5. Request Resolver resolves the request.

Set up Request Resolver with access to Assets, and it has the ability to query Assets as a step in a resolution plan. For example, it can check which device belongs to the requester, if the step is called out in the runbook.

Set boundaries for Request Resolver

Request Resolver runs only on the request types you select in a space. Once enabled, it generates a plan for every new request.

We suggest you configure each request type independently. Start with one or two high-volume, well-documented request types and expand as your team's confidence grows.

You also define how Request Resolver operates. There are two available modes:

  • Supervised mode. Drafts a plan, waits for an agent to review it, then delivers the approved plan to completion. Agents can refine the plan in chat before it runs. This is the recommended starting mode for every request type.

  • Autonomous mode. Resolves a request end to end with no human involvement. It delivers only within the permissions and tool scopes configured for Request Resolver and its connected systems.

Only graduate a request type to autonomous mode once supervised plans are consistently approved without edits.

Read more about execution modes

What can Request Resolver read?

When enabled for a request type, Request Resolver has access to read the following content:

Source

What it reads

How to optimize

Work item context

 

  • Title

  • Description

  • Comments

  • Every Jira Service Management field on the request

Clear request details and well-populated fields produce better plans.

Forms, attachments, and images

 

  • Forms attached to the request (including ProForma forms)

  • Attachments

  • Images (with text)

For example, it can read an error message in a screenshot.

Use forms to collect the structured information your runbooks depend on.

Internal knowledge base

  • Knowledge documents linked to the project, such as runbooks

  • Images and attachments inside runbooks alongside the written steps.

  • Link the internal knowledge base or runbook your human agents already use. No special format required.

  • Include screenshots or reference files where they help resolve the request.

Resolved work items

Refers to previously resolved work items when documentation for a request type is thin or outdated.

Use this when a suitable runbook is missing or incomplete. Writing a runbook remains the more reliable path.

Admin guidance

Applies project-wide instructions to every plan in the project.

Create a page titled "Admin guidance" in the connected knowledge space and document the common steps, policies, and escalation rules that apply across request types.

Manage a resolution plan

A key output from Request Resolver is the resolution plan it generates.

Plan transparency is baked-in to the process. Request Resolved shows each step it intends to take and cites the sources it used, so agents can inspect the reasoning before they approve.

If there’s ever anything that needs changing, agents can edit a plan in Request Resolver chat.

In supervised mode an agent can replace, remove, or reorder steps in chat before running the plan. Request Resolver will refer to any of the edit made to a plan to improve how it handles similar requests in the future. Overall plan quality is likely to improve as your team reviews and refines real work.

How Request Resolver interacts with requests

Irrespective of whether Request Resolver is running autonomously or in supervised mode, it will follow a sequence of prescribed actions to work through a request, such as:

  • Posts public comments to the requester and internal comments to agents.

    • You can use runbook instructions to define when and what Request Resolver should communicate.

  • Tag the requester when information is missing, then resumes the plan when the answer arrives.

    • You can define the required inputs in the runbook or collect them through a form.

  • Tag the requester's manager or any named individual when an approval is needed. Request Resolver will pause, wait for the decision, then resume, and close the request.

    • No agent intervention required!

  • Triage the request, update custom fields, and transition work items through to Resolved or Closed.

    • You will need to set up the runbook guidance.

  • Tag an agent when it cannot proceed or when the runbook says a human must act, then resume automatically when a comment clarifies the path forward.

    • You can use the runbook to define handoff criteria and the right human owner.

Read more about how to set up Request Resolver to resolve work items

Connect third-party tools

Request Resolver can perform actions in tools outside of Atlassian as a step in it’s plan, such as adding a user to a group in your identity provider.

Once set up, Request Resolver will perform the action as it appears in a runbook, within the scope and permissions you’ve granted for that connection.

Read more about connecting external tools

What Request Resolver doesn't do

Request Resolvers works with service requests only — it doesn’t handle incidents.

Because it works after a request is submitted, it does not deflect or answer questions in the Help Center. Work with the Portal Deflection agent instead

Request Resolver doesn’t work with external knowledge. It uses the internal knowledge base your agents read, not the customer-facing knowledge base.

It is designed for high-volume, well-defined requests. Keep complex, judgement-heavy request types in supervised mode, or to your agents.

Get the most out of Request Resolver

Here’s some handy tips to get started:

  • Start supervised on one or two request types with a clear runbook, then expand.

  • Write runbooks like you would for a new starter. Use plain language and clearly define steps. Don’t assume any prior knowledge.

  • Define communication and handoff rules in the runbook. The agent only communicates and escalates as instructed.

  • Review and edit plans early. Each edit improves future plans for that request type.

  • Expand one request type at a time. Enable the next request type once the current one runs cleanly in supervised mode.

Request Resolver is a premium AI feature that consumes Rovo credits. Find out how Rovo credits work for premium AI features.

 

Still need help?

The Atlassian Community is here for you.