What Request Resolver can resolve

Request Resolver resolves service requests the way a member of your team would: it reads your internal knowledge base, generates a plan for each incoming request, and carries the plan out, after a team member reviews it, or on its own.

What Request Resolver can resolve?

Request Resolver handles five kinds of service requests. Find the one closest to your request type, check what it needs, then copy the matching sample runbook.

Access and entitlement requests. Granting, changing, or removing access: read-only or role-based access to a system, membership in a security group or distribution list, access to a shared mailbox or team space, contractor access and extensions, joiner, mover, and leaver entitlement changes, and application assignment or license reclaim. You need an internal knowledge base article with the runbook, plus an identity tool such as Okta, IdentityNow, or Microsoft Entra.

Account and credential support. Restoring access to an account someone already has: password resets, account unlocks, MFA re-enrolment, session revocation, and reactivating a disabled account. You need an internal knowledge base article whose runbook spells out how the requester's identity is verified, plus an identity tool such as Okta, IdentityNow, or Microsoft Entra. Stay supervised here, and keep someone in the loop for anything related to account security.

Knowledge-based answers. Answering a question rather than taking an action: how-to questions, policy questions, process guidance, and entitlement questions, such as "what access do I need for system X?" Request Resolver cites the article it answered from. All you need is an internal knowledge base; no tools required. Start supervised, then switch to autonomous after a few plans. There's nothing to undo.

Request triage and handling. Working the request itself, end to end: classifying and assigning an incoming request to the correct request type, confirming and closing requests the runbook says are already satisfied, posting the resolution and notifying the requester, and routing out-of-scope requests onward. You need runbooks that spell out which request type, which team, and which status to use. Stay supervised until the routing is consistent. See the Admin Guidance pattern in Write knowledge Request Resolver can follow.

Connected-tool actions. Carrying out the steps that touch a connected third-party tool, such as adding someone to an Okta or Microsoft Entra group, assigning an application, or similar. The tool must be connected and configured for your space before Request Resolver can act in it.

Most teams start with access and entitlement requests and knowledge-based answers. Both are high-volume, repeatable, and well-documented.

What it doesn't do

• Incidents, changes, or problems. Service request types only.

• The help center or portal. It acts after a request is raised, not before. For deflection before a request exists, see the portal deflection agent.

• External knowledge. It reads your internal knowledge base, not customer-facing articles.

• Complex or novel requests. It's built for repeatable, well-documented work a new hire could follow a runbook for.

• Protected health information. Request Resolver is not HIPAA compliant.

• Automated decisions with legal or similarly significant effect on individuals. Keep those request types supervised or off.

Examples

The following examples cover common request types and are grouped by scenario. Each follows the guidance in Write knowledge Request Resolver can follow and is ready to adapt for your internal knowledge base. Before each runbook, you’ll find the recommended execution mode, required tools and an example of the generated plan. Review each sample and tailor it to your workflow before use.

These examples assume that your knowledge base also has an Admin Guidance article covering space-wide status rules. Those rules define when requests move from In Progress to Waiting for Customer, then to Escalated, Pending and Resolved. The runbooks below include only status changes specific to their topics. Names, teams, groups and URLs are illustrative; replace them with your own.

Access and entitlement requests

Example 1: Figma access

Recommended mode: supervised to start; autonomous once plans are consistent.

Tools needed: Okta, Microsoft Entra, or IdentityNow, connected and configured. The example uses Okta, but you can update the runbook for Microsoft Entra or IdentityNow.

What the plan usually looks like: ask which seat type if missing (wait for manager approval if Editor) add to Okta group set labels comment resolve.

Knowledge: Sample runbook: Figma access

Sample 2: Distribution list membership

Recommended mode: supervised for the first few, then autonomous. It's low risk and repeatable.

Tools needed: Okta, Microsoft Entra, or IdentityNow.

What the plan usually looks like: look up the list (wait for owner approval if restricted) → add or remove comment resolve.

Knowledge: Sample runbook: Distribution list membership

Account and credential support

Sample 3: Password reset

Recommended mode: supervised. Keep a person in the loop for account security.

Tools needed: Okta, Microsoft Entra, or IdentityNow.

What the plan usually looks like: verify identity (manager approval if on behalf of someone) → trigger reset comment wait for confirmation resolve.

Knowledge: Sample runbook: Password reset

Knowledge-based answers

Sample 4: VPN setup ("How do I…?")

Recommended mode: autonomous once you've checked a few plans. There's nothing to undo.

Tools needed: none.

What the plan usually looks like: find the article answer with a link resolve, or escalate if no article covers it.

Knowledge: Sample runbook: New VPN connection or Sample runbook: VPN troubleshooting

Adapting these samples

• Replace every placeholder (group names, article titles, team names, URLs) with yours.

• Keep the shape: When to use this numbered steps with bold conditions exact field and status changes canned replies as quotes Custom instructions at the end.

• Run each one in supervised mode first, even the ones marked autonomous. Review five or six plans before switching.

• When a plan misses a step, fix the article, not just the plan.