Skip to content
KeystoneOps KeystoneOps Docs

Admin shell — what's where

For admins

The admin shell

Section titled “The admin shell”

The admin shell is where you configure the helpdesk — its forms, rules, queues, SLAs, and people. It’s not where you work tickets (that’s the agent shell) and it’s not where requesters raise them (that’s the portal).

Subsections

Section titled “Subsections”

The left rail groups admin pages into themed bands:

  • Insights — dashboards, reports, queue depth charts
  • Tickets — types, statuses, priority matrix, ticket templates, the triage tree
  • Routing & SLA — departments, SLA policies, business hours, automation, approvals
  • Lifecycle — change freezes, problem rules, project templates

Most of your initial setup lives in Tickets and Routing & SLA.

Setup order for a new trust

Section titled “Setup order for a new trust”

If you’re standing up the helpdesk fresh, do it in this order — earlier steps are dependencies for later ones:

  1. Departments (Routing & SLA) — IT, Estates, HR, Finance, etc. Even if you only have one helpdesk team, set this up; it’s used everywhere downstream.
  2. Business hours (Routing & SLA) — keep the default Mon–Fri 9–5 if it fits, or add term-time-only / 24/7 calendars.
  3. Priority matrix (Tickets) — the standard ITIL grid is fine to start. Tweak per-dept matrices later as you learn how each team thinks about urgency.
  4. Statuses + types (Tickets) — use the seeded ones first; only add custom statuses once you’ve felt a real workflow gap.
  5. SLA policies (Routing & SLA) — start with the default catch-all. Add per-department or per-priority policies once you’re seeing breach patterns in reports.
  6. Ticket templates (Tickets) — the highest-leverage thing on this list. Each template you author saves dozens of agent–requester back-and-forths over time.
  7. Triage tree (Tickets) — wire the templates into the wizard.
  8. Automation (Routing & SLA) — last; encode the routing/escalation moves your team is doing manually.
  9. Users → departments (in the Platform admin) — assign agents to departments so their queues are scoped properly.

You can always come back and tune. Don’t try to perfect any one of these before moving on.

What the admin doesn’t do

Section titled “What the admin doesn’t do”

The admin shell isn’t where you:

  • Work tickets — that’s the agent shell, accessible via the icon rail
  • Manage knowledge base articles — that’s also in the agent shell (KB authoring is curatorial work the team does, not infrastructure)
  • Manage user identities — that’s in the Platform admin (users, roles, SSO)

If you need to cross those boundaries, the icon rail on the far left switches you between products.