Recording a change
Recording a change
New change on the Changes page: the service, the type and what changes. Fill in the rest on the change's page:
- What and why, and what customers will notice, in plain words.
- Risk: a few questions (has it been done before, can it be backed out, will customers notice, has it been tested). The answers add up to low, medium or high; a tier 1 service raises it one step. The owner (or a Change Manager) can set the risk by hand, with a reason; lowering it is listed as an exception.
- Plans: implementation, test, backout and communication, in Markdown. Which are required depends on the type and risk (Settings).
- The window when it happens, checked against the services' change windows and freezes.
- Owner, implementer and tasks for changes where several people take part.
- Links to cases, incidents and dev tasks. From a case, Open change in its menu links the two; from an incident, Emergency change opens one for the fix.
- Customers: the accounts affected (see Customers).
The calendar
Calendar on the Changes page shows the next four weeks day by day: the changes planned, with their status and risk, and the freezes.
In the inbox and automations
The inbox's views show changes above the cases (see other kinds of work): All open the open ones, Assigned to me those you own, implement or asked for, Unassigned those nobody implements yet, and Resolved and closed the done ones, newest first. Their counts add to the views' counts.
Automations can run on changes: when one is recorded or moves on, or on a schedule, to tell someone, set the implementer or add a note.