Write internal knowledge for Request Resolver

Request Resolver uses the knowledge base connected to your service space to help resolve work items. This knowledge can include articles, runbooks, troubleshooting guides, and other approved information your team uses to handle requests. More about using knowledge base in Jira Service Management

Request Resolver acts directly on what your knowledge articles say. Clear, focused, well-structured articles help it match the right article to each request and follow the steps accurately. Vague, overloaded, or ambiguous articles lead to the wrong article being chosen or steps being missed. The quality of your writing shapes the quality of Request Resolver's resolutions.

This article shows you how to write knowledge articles and runbooks that Request Resolver can find, understand, and act on, with three examples you can copy.

Quick checklist

In a hurry? A knowledge article Request Resolver can use usually includes all of the following:

• Covers just 1–2 related topics, not everything about a tool.

• Has a clear, specific title that matches how requests come in. For example, "Claude access".

• Says when to use it, and when not to.

• Lays out the resolution as short, numbered steps.

• Uses bold for any critical condition Request Resolver must not miss.

• States each field change explicitly, on its own line.

• Names tools, groups and systems exactly as they appear in those systems.

• Calls out topic-specific status rules. General rules go in an Admin Guidance article.

• Puts any canned reply as exact text in a quote block or info panel.

• Writes approvals and waits as explicit steps.

• Keeps custom instructions (3–4 bullets) in their own section at the end.

How Request Resolver uses knowledge

• It reads the internal knowledge base connected to your service space, the same articles your agents read. It doesn't use external, customer-facing articles for resolution plans.

• For each new request of an enabled request type, it finds the matching article, generates a step-by-step plan, and shows which knowledge it used.

• Steps that name a connected tool become actions it performs. Steps it can't perform become points where it pauses and tags a team member.

• It only ever shows help-seekers' information that they have permission to see or that a team member has approved.

The new-hire test

Your articles don't need a special template. The test that matters:

Could a new hire on your team follow this article and resolve the request correctly, without asking anyone anything?

If yes, Request Resolver can follow it. If a new hire would have to ask "which group?", "who approves this?", or "what do we tell the requester?", Request Resolver has the same problem.

ガイドライン

1. Keep each article focused

• Write each article around 1–2 main topics. A focused article is easier to match to the right request.

• Use Claude access or Claude access issues rather than one large Claude article covering access, issues, features and everything else.

• Give it a title that matches how requests come in. Employees write "need Claude access", not "LLM tooling entitlement". Match their words.

2. Say when to use the article

Open with a short When to use this section: what kind of request it covers and what it doesn't. This is what stops Request Resolver from applying a read-only access runbook to an admin access request.

When to use this: Use this runbook when an employee asks for access to Claude or any Claude feature. Not for billing or license-count questions. Those go to Finance.

3. Structure the steps clearly

• Break the resolution into Step 1, Step 2, Step 3. Simple, pointed statements beat verbose guidelines.

• Keep each step short and action-focused: what needs to be done, in order.

• One action per step. Don't combine "check their manager and add them to the group" into one line.

• If a condition or point must not be missed, put it in bold. Request Resolver treats bold as emphasis.

4. Be explicit about field changes

If Request Resolver needs to update a field on the work item, write the instruction clearly, on its own line.

Change the Support Team field to "IT Support".

5. Call out status rules

• If a status rule is specific to this topic, include it in the steps: Change the status to "Waiting for Customer" after posting a question to the requester.

• If a status rule applies across many topics, don't repeat it in every article. Put it once in an Admin Guidance article (see below).

6. Name tools and targets exactly

A step Request Resolver can execute names the system and the object precisely, as they appear in that system:

• "Add the requester to the Okta group Sales-CRM-Users" is executable.

• "Give them CRM access" is not executable.

Say where the input comes from too: "using the requester's email address on the work item", or "ask the requester for their office location in a comment".

Request Resolver can act in Jira Service Management natively including updating fields, commenting to the requester and in connected third-party tools such as Okta, Microsoft Entra, or IdentityNow. A tool must be connected to your space before a step can be run. Find out how to manage Request Resolver’s tools.

7. Put canned replies as exact text

If Request Resolver should post a specific message to the requester, put the exact wording in a quote block or an info panel (type /info in Confluence). Use placeholders like <user_name> for details that should be filled in.

Hi <user_name>, Thanks for reaching out to us. We're checking this and will get back to you shortly.

8. Write approvals and waits as steps

Some steps depend on someone outside your team. Write them so it's clear the step is a wait, not an action:

Step 3. Find the requester's manager and post a public comment tagging them to request approval. Wait for the manager's approval before continuing.

Request Resolver pauses at these steps, waits on the work item, and resumes once the approval or reply arrives.

Regardless of what your article says, Request Resolver also pauses on its own before anything it has low confidence in. For example, irreversible actions like deleting files, closing work items, or sending external emails.

9. Add custom instructions at the end

If Request Resolver needs to follow special rules for this topic, add them near the end in their own section.

• Keep them short: aim for 3–4 bullets.

• Use them for rules such as when not to ask a question or what to avoid doing.

• Don't repeat or contradict the resolution steps.

Create an Admin Guidance article for space-wide rules

Rules that apply to every request, especially status transitions, belong in one Admin Guidance article in the same internal knowledge base, not copied into every runbook. Request Resolver reads it alongside the topic article. Keep it to the rules that genuinely apply everywhere. See the example below.

Finding and fixing gaps

The most common reason a plan goes wrong is a step that lives in someone's head, not in the article. You find these by reviewing plans in supervised mode:

• A missing step means the article doesn't mention it. Add it as its own numbered step.

• A wrong target (wrong group, wrong team) means the article is ambiguous. Use the exact name.

• An unnecessary step means the article covers more than one scenario without saying which applies when. Split it, or add conditions.

• A pause where you didn't expect one means the step isn't written as something Request Resolver can do. Rewrite it, or connect the tool.

When team members correct a plan in the chat, those corrections help future plans for similar requests. But the article is the source. Feed the fix back into it. Expect a handful of one-time fixes per request type in the first week; after that, the article is good for Request Resolver and for your next new hire.

Starting from a thin or outdated knowledge base

Your knowledge doesn't need to be perfect before you start. Begin with the most relevant article for the request type you're enabling, and improve it as you review plans.

If there's no article at all for a request type your team has resolved many times, you can draft one from those resolved work items using Request Resolver's Manage Knowledge Base capability, which reads the description, comments, and activity. For a solid result, generate from around ten resolved work items, merge and tidy the draft, make names exact, and publish it to your internal knowledge base.

The three example articles below follow the guidelines. Names and teams are illustrative; replace them with your own. Each example ends with a "Why it works" note explaining the guideline it demonstrates.

Example 1: a simple access runbook

Title: Runbook: Claude access

When to use this: This runbook is for granting access to Claude. If a user is looking to access Claude or any features related to Claude, use this runbook.

手順

Step 1. We offer two license types: Claude Professional and Claude Enterprise. Check with the user which license they are looking for. If they have already provided this, skip this step.

Step 2. If the user wants the Claude Professional license, triage the work item to the "Level 2: Tech Support" team. Set the Support Team field to "Level 2: Tech Support".

Step 3. If the user wants the Claude Enterprise license, we need their manager's approval first. Find their manager and post a public comment tagging them and requesting approval. Once the manager approves, triage the work item to the "Level 2: Tech Support" team (set the Support Team field to "Level 2: Tech Support").

Step 4. After triaging, post the following comment to the user:

Hi <user>, Thanks for reaching out to us! We have sent this request to the appropriate team. They will grant you the required access.

Other processes to follow

• Immediately after Step 1, set Labels on the work item to "claude-access" and the license type the user is asking for.

Why it works: one topic; a title that matches the request; a "when to use" section; bold on the two conditions that change the path; the field change on its own line; the approval written as a wait; the canned reply as exact text; custom instructions kept separate at the end.

Example 2: a runbook with complex conditions and custom rules

Title: Runbook: Guest Wi-Fi account request

This guide is for support agents handling work items of the Get a guest Wi-Fi account request type.

When to use this: Use this document when a work item requests temporary guest Wi-Fi access for a visitor at an office location. This includes single guests, multiple guests, or event-based visits requiring temporary Wi-Fi access.

Step 1: Review the request

• Confirm the work item is for the Get a guest Wi-Fi account request type.

• Read the Summary and Description to understand the request.

• Identify whether the request is for a single guest, multiple guests, or an event.

• Review the Guest arrival date, Region and Office fields to understand when and where access is needed.

• Time zone: infer from the office city (Atlanta Eastern, Chicago Central, Denver Mountain, San Francisco Pacific, London GMT/BST).

• Dates and times: calculate relative dates from the work item's Created timestamp. Do this yourself. Never ask the customer to confirm what "tomorrow" or any other relative term means. If a date is given but no times, default to 9 am–5 pm local office time. If times are stated in the Summary or Description, use them. Never ask for the date or time window if you can calculate or infer it.

Step 2: Decide how to proceed

• If standard guest Wi-Fi is requested: validate the office and visit timing; inform the requester that another team will provision access; move the work item to the "Escalated" status so the assignee or another support team can grant access; then confirm with the assignee that access has been provided. If yes, continue; otherwise wait for the assignee before proceeding.

• If the request includes unclear VPN expectations: clarify the exact need and confirm whether guest VPN is supported by policy before proceeding.

• If the request is for multiple guests or event-based access: confirm attendee count, timing and office, and follow the local bulk guest access process if available.

• If host, timing or location details are missing: request the missing details in one concise update.

• If access is blocked by a local office, network or policy dependency: document the blocker, notify the requester, and wait for the dependency or handoff.

• If any of the fields needed to decide are missing, post this comment to the requester:

Please provide the missing details needed to complete your guest Wi-Fi request, including the guest name, office location, and visit date if not already included.

Step 3: Resolve the work item

• Once the assignee confirms that guest access has been provisioned, configured, or confirmed complete, resolve the work item.

• Post this comment to the requester:

Your guest Wi-Fi request has been processed. We have completed the required support action and provided the appropriate access details or next steps for the guest visit. If anything about the visit timing, office location, or guest details changes, reply to this request and the support team will review it.

• Move the work item to "Resolved".

Why it works: each branch is a bold condition followed by what to do; the hardest judgment call (relative dates) is spelled out with a rule and an example, so Request Resolver never has to ask; waits on other people are explicit; both canned replies are exact text; the status changes are named.

Example 3: an Admin Guidance article

Title: Admin Guidance

Work item workflow transitions followed in this space

1. Move the work item to "In Progress" when starting work on it.

2. After asking the requester a clarifying question, move the status to "Waiting for Customer".

3. Whenever a work item has to be handled by a different support team (triaging, deflecting or escalating), move it to "Escalated".

4. When waiting for an assignee to complete a task, move it to "Pending".

5. The final state is "Resolved". Whenever a work item is resolved, move it to this state.

Why it works: these rules apply to every request type in the space, so they live in one place instead of being repeated in every runbook. Topic-specific status rules stay in the topic runbook.

What not to put in knowledge for Request Resolver

• Protected health information or anything covered by HIPAA. Request Resolver is not HIPAA compliant.

• Credentials, tokens, or shared passwords.

• Steps that amount to a decision with a legal or similarly significant effect on an individual. Keep those request types in supervised mode or off.