Problems, changes and internal desks: what lives around the case
The support console answers "what is broken now". Two other questions live around it, and until now there was nowhere to write them down: **why does this keep coming back** (a problem) and **what are we about to change** (a change). Both live in Service extensions, together with the dependency map,
The support console answers "what is broken now". Two other questions live around it, and until now there was nowhere to write them down: **why does this keep coming back** (a problem) and **what are we about to change** (a change). Both live in Service extensions, together with the dependency map, the internal desks and the configuration packs.
Problems: the cause behind the cases that repeat A problem is not a second case. It has no SLA, no channel and no queue, and it never shows up in your support numbers. It exists to hold two texts:
- the **workaround**, which is what the agent can tell the customer today;
- the **root cause**, which is what has to be fixed so it stops.
Link the cases that the problem explains. From then on, whoever opens one of those cases sees the workaround in the console, and the AI tool `known_errors_for_case` can quote it too.
Two rules are enforced by the server, not only by the screen: - marking a problem as a **known error** requires the workaround written down. A known error with nothing to tell the customer is just a problem with a better name; - **resolving** requires the root cause, the same rule the major incident already asks for.
A problem that has cases linked is not deleted. Close it: the history of what explained those cases stays.
Changes: what will be touched, and when A change carries a window, an implementation plan, a **backout plan** and, when the type asks for it, an approval. Types follow the usual vocabulary:
- **pre-approved**: routine work whose approval was given once, in the procedure. It never opens an approval request;
- **normal**: goes through your approval policy, the same engine as every other approval in the product;
- **emergency**: the fix for something already broken.
Mark the equipment the change touches. That is what makes two useful checks possible before you commit to a night:
- **freeze periods** (month end, peak season) block anything planned inside them. Emergencies pass when the freeze allows it, because freezing the emergency is freezing the repair of what is already broken;
- **collisions**: another change touching the same equipment in an overlapping window. This one only warns. Two teams may, knowingly, work on the same server on the same night; nobody should work during a freeze by accident.
Scheduling without a backout plan is refused. Registering a failure or a rollback without saying what happened is refused too: the note is the whole point of reading this six months later.
The dependency map The configuration item is the installed asset the case already points to, not a fourth register of equipment. Draw who depends on whom (depends on, runs on, part of, connected to, backs up) and the map answers the question of the night: **what stops when this stops**, with the number of cases already open on each impacted item. A relation that would close a hierarchical cycle is refused, and when the traversal reaches its depth limit the screen says the list is partial instead of pretending it ends there.
Internal desks (HR, IT, finance) A desk is where your own people ask the internal team for something. There is no external portal: whoever asks is already signed in. The desk declares the queue, the priority and, when it matters, that the subject is **confidential**.
Confidential is not decoration. The case is born restricted: only people with the sensitive case permission open it, and every read is recorded. That is the same guard the product already had, not a second one.
A desk with requests is not deleted, it is deactivated. Deactivating means "do not ask for this any more"; it never cancels what is already open.