Troubleshoot Request Resolver

Find the symptom you're seeing, then work through the likely causes in order.

I can't find Request Resolver in space settings

Likely causes

• AI isn't activated for Jira Service Management on your site. An organization admin needs to turn it on in Atlassian Administration.

• You're not a space admin. Request Resolver settings are only visible to space admins.

• Your plan doesn't include it. Request Resolver is available for all Standard, Premium, and Enterprise plans with AI enabled for your org.

No plan was generated for a request

Likely causes

• The request type's execution mode is None. Set the execution mode for that request type to Supervised or Autonomous in the Execution tab of Request Resolver in your space settings’ AI agents page.

• It isn't a service request type. Request Resolver works only on service request types, not incidents, changes, or problems.

• Request Resolver couldn't generate a plan. This happens when there's no relevant knowledge to draw on. Check that an internal knowledge base article covers this kind of request, and that Request Resolver has access to it under Knowledge. No credits are used when a plan can't be generated.

• Request Resolver doesn't have access to the knowledge. The person who set up Request Resolver needs permission to access the Confluence spaces used as knowledge.

• Request Resolver doesn't have permission to access the work item. Work item security settings may be blocking it. Add Request Resolver to the relevant security level.

The plan uses the wrong knowledge, or none at all

Likely causes

• The right article is external, not internal. Request Resolver uses the internal knowledge base for resolution plans. Under Knowledge base settings, make sure the article is available under Internal.

• Two articles overlap. If two runbooks cover similar requests without specifying when each applies, Request Resolver may pick the wrong one. Add a clear "When this applies" section to each, or merge them.

• The article doesn't mention the request the way employees phrase it. Add the common phrasings employees use. The words in the request are what Request Resolver matches on.

The plan is missing a step or has an extra one

This is almost always a knowledge problem, not a Request Resolver problem.

• Missing step: the runbook doesn't mention it. Add it as its own numbered step.

• Extra step: the runbook covers more than one scenario. Split it, or add conditions ("If the requester is a contractor…").

• Wrong target (wrong group, wrong system): the runbook is ambiguous. Use exact names.

Fix the runbook, then regenerate the plan. Regenerating a plan for the same request doesn't use additional credits. See Write knowledge Request Resolver can follow.

Request Resolver paused and hasn't resumed

Request Resolver pauses and tags a team member when it:

• reaches a step that needs a tool that isn't connected. Connect it under Tools, or do the step yourself, then select Resume plan.

• has low confidence about a step, typically irreversible actions such as deleting files, closing work items, or sending external emails, or actions it doesn't have access to perform. Review the step, do it or approve it, then select Resume plan.

• is waiting for an approval or a reply from the requester or an approver. Check the work item comments to see what it's waiting for.

In autonomous mode, paused work items are easy to miss. Set up the Request Resolver status custom field and a queue to see them. See Track work items Request Resolver is working on.

A tool step failed

Likely causes

• The tool's authentication has expired or was set up by someone who has since lost access. Go to Tools and re-authenticate.

• The group, application, or object named in the runbook doesn't exist or is spelled differently in the tool. Correct the name in the runbook so it matches exactly.

• The connected account doesn't have permission to perform that action in the third-party tool. Check the account's role in Okta or IdentityNow.

Plans aren't getting better

Request Resolver improves as your team edits plans in supervised mode and as you improve the knowledge behind them. If quality isn't improving after five or six similar requests:

• Edits aren't being made in the chat. Team members may assign Request Resolver without correcting the plan or fixing issues manually afterward. Ask them to state changes in the chat window before assigning.

• The runbook hasn't been updated. Plan edits help, but the runbook is the source. Feed the corrections back into it.

• The request type is too broad. If a single request type covers many scenarios, plans will vary. Consider splitting it into more specific request types.

Request Resolver is doing something I don't want

Select Stop under Resolution plan on the work item. Request Resolver stops immediately.

To stop it for a whole request type, set that request type's execution mode to None under Execution.

Credits are being used faster than expected

Request Resolver uses 100 Rovo credits each time it generates a plan for a request. It doesn't use credits for regenerating a plan, editing it, or executing it. If usage is higher than expected:

• Check which request types have an execution mode set. Every incoming request of those types generates a plan, including test requests and requests that later get closed as duplicates.

See Rovo credits for Request Resolver.

それでも問題が解決されない場合

Ask the Atlassian Community, or contact support.