LooplineGuide
/
Sign in

Change requests

Raise a change, schedule it, get it approved by the CAB, and close it — and what stops a change from closing.

Tickets → New ticket

A change request is a ticket for planned work on something people depend on: a server upgrade, a configuration change, a new release. It carries a change type, a planned window and, on plans that include it, a Change Advisory Board (CAB) approval. Together these decide when the work may go ahead and when the ticket may close.

Raise a change

  1. Go to Tickets and choose New ticket.
  2. Pick the project and set Type to your workspace's change tracker (usually called Change).
  3. In the Change classification block, choose a Change type: Standard, Normal or Emergency. You can leave it at Not classified yet and set it later.
  4. Set Planned start and Planned end if you already know the window, then create the ticket.

You can also raise a change from a problem. On the problem, choose Create Changeabove the list of linked tickets, give it a title and a change type, and choose Create Change. The new change is created in the problem's project and linked to it as fixed by.

What the change type decides

  • Standard and Normal changes need an approved CAB request before they can be closed, on plans that include Change Approval Board. Each type has its own approver chain — see CAB approval chains.
  • Emergency changes skip that rule: the work is done first and reviewed afterwards. Instead, an Emergency change cannot close until its Post-Implementation Review (PIR) is marked complete.
  • A freeze window can let Emergency changes through while still holding back the other types. Each window says whether it does.

You can change the type at any time in the Change classification & schedule section of the ticket. The rules above follow whatever the type is when the change is closed.

Schedule the work

The Change classification & schedule section on the ticket holds the type and the planned window. Edit them there, then choose Save changes at the top of the ticket. Once both dates are set, the section checks the window:

  • Overlapping changes — if other scheduled changes overlap this window, the section lists their keys. This is only a warning.
  • Change freezes — if the window falls inside a freeze, a notice names each window and says whether submitting will be refused or only flagged. That depends on how your admins set up change freeze windows.

A change with a planned start shows on the change calendar.

Risk score

On plans that include Change Approval Board, every change shows a risk score from 0 to 100, worked out from your own delivery history. Your admins choose whether a high score only warns or actually blocks submission for approval. See Change risk scoring.

Submit for CAB approval

  1. Make sure a change type is chosen and saved. Submit for CAB approval stays disabled until a type is picked.
  2. In the CAB approval box on the ticket, choose Submit for CAB approval.
  3. The configured approvers are asked in order, and their progress shows in the same box. Approvers decide from Approvals or the CAB Agenda.

Submitting is refused when:

  • the change has no type yet;
  • no approver chain is set up for its type (ask an admin to add one);
  • the change already has a pending CAB request;
  • your workspace blocks high-risk changes and this one scores too high;
  • your workspace blocks changes in a freeze, the planned window falls inside one, and the change is not an Emergency change that the window lets through.

Available on plans that include Change Approval Board.

Implement and close

Move the change through your workflow's statuses as the work goes ahead. Closing it means moving it to a final status. That move is refused when:

  • it is a Standard or Normal change, or has no type yet, and has no approved CAB request (on plans that include Change Approval Board): "This change needs an approved CAB request before it can be closed."
  • it is an Emergency change and its PIR is not complete: "This Emergency change needs a completed Post-Implementation Review before it can be closed."

To complete the PIR on an Emergency change, find the Post-Implementation Review box, write what happened, what was done and any follow-ups, and choose Mark PIR complete. The box then shows Completed with the time and your notes.

To record a change that failed or was rolled back, close it in a final status whose category is not Done (a "Cancelled" or "Rolled back" status, for example). The Change success rateon the Reports page counts a change as successful only when it closed in a Done-category status.

Related