Skip to content

Core Tools

How Documentation and the knowledge base work

How Documentation is populated, how it's searched, and how it connects to Courses.

Documentation is the in-app knowledge base, reached from Knowledge in the sidebar. Unlike a static help wiki, it is substantially populated by real work: every ticket you resolve auto-publishes a formatted document built from your work notes, resolution notes, and resolution code. Over time, your own closed tickets become searchable reference material — both for you and, on a shared account, for the technicians who come after you. This is a deliberate design choice: instead of a knowledge base someone writes once and everyone reads, it's a knowledge base your actual work builds continuously.

Using Documentation

  1. Open Documentation and use the search field to look up a symptom, a system, or a keyword, or filter by document type to narrow the list.
  2. Open an article to read the full write-up — for auto-published tickets, that includes the original symptom, the investigation, and the resolution exactly as you documented it.
  3. Reference an existing article the next time a similar ticket comes in, rather than re-deriving the same fix from scratch.

This is also the mechanical reason resolution notes are graded on substance rather than presence, as described in How Tickets Work — a note that just says "fixed it" produces a document that is useless to the next technician who searches for that symptom. Writing a real note is not busywork on top of the ticket; it is the actual content of the knowledge base. A well-written resolution note pays off twice: once immediately, in your ticket's process score, and again later, whenever that document surfaces for a similar incident.

Documentation is filtered by document type so you can narrow a search to the kind of reference you actually need — troubleshooting write-ups auto-published from resolved tickets, versus other categories of reference material seeded into the base. Because the search covers full article content and not just titles, looking up a specific error message, service name, or symptom phrase is usually enough to surface the right prior ticket even if you don't remember exactly what it was called.

Courses sits alongside Documentation under Knowledge in the sidebar. Where Documentation is reference material generated from real tickets, Courses is structured, authored lesson content with understanding checks and section quizzes — a deliberately different kind of learning from either the reactive, work-as-you-go nature of Documentation or the live, judged nature of Interview practice. All three live under Knowledge because they are all forms of building capability, just through different mechanisms: Courses teaches concepts up front, Documentation captures what you and others have actually done, and Interview tests whether you can explain it out loud.

It is worth repeating the distinction from the top of this Help Center here specifically, because Documentation is the SysDesks feature people most often confuse with the public blog: Documentation is generated from and scoped to what happens inside your account's simulated environment, while the blog is public, general IT-support writing meant to rank on search and be useful to anyone, signed in or not. If you're looking for general troubleshooting methodology rather than a record of what you or another technician actually did on a SysDesks ticket, the blog is the right place, not Documentation.

The connection between a ticket and its documentation runs both ways: the ticket workspace has its own Documentation panel showing the article that ticket published once resolved, and a link back to browse the full knowledge base from there, so you can move from a specific ticket to the wider library of past work and back again without losing your place.

There's no separate step to "submit" a ticket to Documentation and no delay before it appears — the moment you resolve a ticket with a valid resolution code, its article exists and is immediately searchable. This near-instant publishing is part of why the knowledge base stays genuinely current rather than trailing behind actual work by days or weeks the way a manually maintained wiki often does.