New Page

Escalation: Teams, Queues & Routing

When to use this page: You've hit the ceiling of a page's own "If it doesn't work → Escalate to" line and need to know where an issue actually goes — which queue or which person — based on the system it's about or the task being attempted.

Prerequisites: None to read. To change a route, oit-editor access and the note-in-reviewer-notes discipline below.

Important: Routing targets change (people move teams, queues get renamed). Treat the routing: block below as the source of truth and keep the human tables in sync with it. If a KB page names an escalation team inline, it should instead say "escalate per [[Escalation: Teams, Queues & Routing]]".

How routing works (read this first)

Two things about any escalation:

What it's keyed on. You can route on the system (duo, peoplesoft, setpassword, …) or on the task (password-reset, mfa-reset, access-grant, …). Most escalations match on one of these; some match on both.

What it targets. A route points at either a person (a named owner) or a queue (a team inbox / RT queue). Person routes are for cases with a clear single owner; queue routes are for anything a team picks up collectively. When a person is out, their route falls back to the queue named in their entry.

Precedence — when more than one rule could match, the most specific wins:

by_system_task (a system and task combination) → by_task → by_system → default_queue.

So an Active Directory password reset matches the password-reset task rule (Heather) before the active-directory system rule — task beats system unless a combined by_system_task rule is defined for that exact pair. This is deliberate: it lets a task owner cut across every system, while combined rules carve out the exceptions.

Routing by system

Task	System	Goes to	Type
password-reset	`setpassword`	Heather Palmeter	person
password-reset	`active-directory`	Heather Palmeter	person
---	`active-directory`	Quincy Wood	person
---	`mycu`	Admin Computing	queue
---	`google-workspace`	Identity & Access	queue
---	`duo`	Marcus Reed	person
---	`peoplesoft`	Tom Delgado	person
---	`kronos` · `cbord` · `slate`	Enterprise Applications	queue
---	`moodle`	Sara Kwon	person
---	`echo360` · `voicethread`	Teaching & Learning	queue
---	`verizon`	Devin Osei	person
---	`mitel`	Telecom & Mobile	queue
---	`vpn` · `eduroam` · `polaris`	Systems & Network	queue
---	`papercut` · `appsanywhere` · `zoom` · `snipe-it`	Endpoint Engineering	queue
---	`wordpress`	Ray Chen	person
---	`drupal`	Web & CMS	queue
---	`rt`	Help Desk (tier 1)	queue

Routing by task

Task	Goes to	Type
`password-reset`	Heather Palmeter	person
`mfa-reset`	Marcus Reed	person
`account-create` · `account-disable` · `access-grant`	Identity & Access	queue
`install`	Endpoint Engineering	queue
`config`	Systems & Network	queue
`troubleshoot` · `reference`	Help Desk (tier 1)	queue

Exceptions (system + task combined)

These override the task default for one specific pairing:

System + task	Goes to	Why
`peoplesoft` + `access-grant`	Tom Delgado	PeopleSoft grants need the app owner, not the general access queue
`duo` + `mfa-reset`	Marcus Reed	Duo resets stay with the Duo owner

Routing table (machine-readable)

An agent reads the routing: block; humans can use the mirrored tables underneath. Keep the two in sync — the block wins if they ever disagree.

routing:
  default_queue: helpdesk-tier1
  precedence: [by_system_task, by_task, by_system, default_queue]

  # target: person | queue
  # every person entry names a fallback_queue for when that person is unavailable

  by_task:
    password-reset:   { target: person, id: hpalmeter, name: "Heather Palmeter", fallback_queue: identity-access }
    account-create:   { target: queue,  id: identity-access }
    account-disable:  { target: queue,  id: identity-access }
    mfa-reset:        { target: person, id: mreed,     name: "Marcus Reed",       fallback_queue: identity-access }
    access-grant:     { target: queue,  id: identity-access }
    install:          { target: queue,  id: endpoint-deployment }
    troubleshoot:     { target: queue,  id: helpdesk-tier1 }
    config:           { target: queue,  id: systems-network }
    reference:        { target: queue,  id: helpdesk-tier1 }

  by_system:
    setpassword:      { target: person, id: hpalmeter, name: "Heather Palmeter", fallback_queue: identity-access }
    active-directory: { target: queue,  id: identity-access }
    mycu:             { target: queue,  id: identity-access }
    google-workspace: { target: queue,  id: identity-access }
    duo:              { target: person, id: mreed,     name: "Marcus Reed",       fallback_queue: identity-access }
    peoplesoft:       { target: person, id: tdelgado,  name: "Tom Delgado",       fallback_queue: enterprise-apps }
    kronos:           { target: queue,  id: enterprise-apps }
    cbord:            { target: queue,  id: enterprise-apps }
    slate:            { target: queue,  id: enterprise-apps }
    moodle:           { target: person, id: skwon,     name: "Sara Kwon",         fallback_queue: teaching-learning }
    echo360:          { target: queue,  id: teaching-learning }
    voicethread:      { target: queue,  id: teaching-learning }
    verizon:          { target: person, id: dosei,     name: "Devin Osei",        fallback_queue: telecom-mobile }
    mitel:            { target: queue,  id: telecom-mobile }
    vpn:              { target: queue,  id: systems-network }
    eduroam:          { target: queue,  id: systems-network }
    polaris:          { target: queue,  id: systems-network }
    papercut:         { target: queue,  id: endpoint-deployment }
    appsanywhere:     { target: queue,  id: endpoint-deployment }
    zoom:             { target: queue,  id: endpoint-deployment }
    snipe-it:         { target: queue,  id: endpoint-deployment }
    wordpress:        { target: person, id: rchen,     name: "Ray Chen",          fallback_queue: web-cms }
    drupal:           { target: queue,  id: web-cms }
    rt:               { target: queue,  id: helpdesk-tier1 }

  # exceptions: a specific system+task pair that should NOT follow the task default
  by_system_task:
    "peoplesoft/access-grant": { target: person, id: tdelgado, name: "Tom Delgado", fallback_queue: enterprise-apps }
    "duo/mfa-reset":           { target: person, id: mreed,    name: "Marcus Reed",  fallback_queue: identity-access }

Queues (team inboxes)

Queue id	Team	RT queue / inbox	Handles	Coverage
`helpdesk-tier1`	OIT Help Desk (front line)	RT: Help Desk	Default catch-all; triage, general troubleshoot, reference	Mon–Fri 8:00–16:30
`admin-computing`	Admin Computing	RT: Admin Computing	Default catch-all for the Adm,in Computing Team, assigned internally	Mon–Fri 8:00–16:30
`identity-access`	Identity & Access Management	RT: Accounts	AD, myCU, Google Workspace, account lifecycle, access grants	Mon–Fri 8:00–17:00
`systems-network`	Systems & Network Engineering	RT: Systems	VPN, eduroam, Polaris, DNS/IP, server config	Mon–Fri 8:00–17:00, on-call after hours
`enterprise-apps`	Enterprise Applications	RT: Enterprise Apps	PeopleSoft, Kronos, CBORD, Slate	Mon–Fri 8:00–17:00
`teaching-learning`	Teaching & Learning Technologies	RT: TLC	Moodle, Echo360, VoiceThread	Mon–Fri 8:00–17:00 (extended during term)
`telecom-mobile`	Telecom & Mobile	RT: Telecom	Mitel/voice, Verizon lines & devices	Mon–Fri 8:00–17:00
`endpoint-deployment`	Endpoint Engineering	RT: Endpoints	Imaging, software/install, PaperCut, AppsAnywhere, Zoom tooling, Snipe-IT	Mon–Fri 8:00–17:00
`web-cms`	Web & CMS	RT: Web	WordPress, Drupal, webspace	Mon–Fri 8:00–17:00
`av-signage`	AV & Digital Signage	RT: AV	Classroom AV, event support, Concerto signage	Mon–Fri 8:00–17:00, event on-call
`security`	Information Security	RT: InfoSec	Suspected compromise, sensitive-data incidents, MFA fraud	Mon–Fri 8:00–17:00, 24/7 on-call for incidents

Warning: Anything that looks like a security incident (account takeover, phishing hit, sensitive-data exposure) skips normal routing and goes straight to security — do not sit it in a system/task queue.

People (named owners)

Owner id	Name	Owns (system / task)	Fallback queue
`hpalmeter`	Heather Palmeter	system `setpassword`, task `password-reset`	`identity-access`
`qwood`	Quincy Wood	system `active-directory`, task `gpo-update`	`inetwork-services`
`tdelgado`	Tom Delgado	system `peoplesoft`, combo `peoplesoft/access-grant`	`enterprise-apps`
`skwon`	Sara Kwon	system `moodle`	`teaching-learning`
`dosei`	Devin Osei	system `verizon`	`telecom-mobile`
`rchen`	Ray Chen	system `wordpress`	`web-cms`

Verification

To confirm a route: read the routing: block, apply precedence (by_system_task → by_task → by_system → default_queue), and check the resulting id against the Queues or People table for the current owner/inbox.

An agent answering "where does X go?" should return the matched rule key and the target id, then resolve the id to a name/queue via the tables above.

If a route is wrong or missing

No rule matches → it falls to default_queue (helpdesk-tier1) by design; if that's the wrong home, add a by_system or by_task rule rather than leaving it to the catch-all.

Owner has left / queue renamed → update the routing: block and the mirrored table in the same edit, then re-stamp last_reviewed.

Escalate to: identity-access for account/identity routing disputes; helpdesk-tier1 lead for anything else you can't place.

Notes

Person routes always carry a fallback_queue so nothing dead-ends when someone is out.

Keep system/task values drawn from the controlled vocabulary in the KB Blueprint — do not invent route keys the tag schema doesn't recognize.

meta:
  audience: helpdesk
  system: escalation          # proposed new tag value — this page is cross-system (see Reviewer notes)
  task: reference
  tier: tier1
  aliases:
    - "who do I escalate to"
    - "escalation team"
    - "which queue"
    - "route this ticket"
    - "who owns duo"
    - "password reset owner"
    - "hand off to"

review:
  last_reviewed: 2026-07-01
  reviewed_by: hpalmeter
  volatility: medium
  cadence_days: 180
  next_due: 2026-12-28
  canonical_source: internal
  status: current
  verify:
    - "Every `id` in the routing block still resolves to a live person or RT queue in the Queues/People tables"
    - "RT queue names in the Queues table still match the actual RT queue list"
    - "setpassword system and password-reset task still route to Heather Palmeter (hpalmeter)"
    - "No KB page hard-codes an escalation team that contradicts this routing block"

Reviewer notes

Real vs. placeholder: the only confirmed routes are system setpassword → Heather Palmeter and task password-reset → Heather Palmeter. Everything else (all other people, all queues, all other system/task routes, coverage hours, RT queue names, the two combined exceptions) is placeholder for page buildout.

New tag value: this page is inherently cross-system, so meta.system uses a proposed new value escalation. Add it to the Blueprint tag vocabulary before publishing, or swap it for whatever you prefer (helpdesk-ops?).

Precedence choice: I set task to beat system (by_task before by_system) so an AD/Google/myCU password reset still lands on you rather than the Identity queue — that keeps your two real routes behaving consistently. Flip precedence if you'd rather system win by default.

Structure to modify: the routing: YAML block is the machine-readable source; the tables above it are the human mirror. If you change routing, edit both. The by_system_task section is the extension point for one-off exceptions.

Fallback design: every person route names a fallback_queue so no escalation dead-ends when an owner is unavailable — confirm the fallbacks are the ones you want.

BookStack tags

audience:helpdesk · system:escalation · task:reference · tier:tier1 · volatility:medium · review-status:current