Change Management Guide
Manage infrastructure changes with structured approval workflows, risk assessment, rollback planning, and full audit trails.
Overview
Change Management in ForsetiDesk provides a formal process for requesting, reviewing, approving, and implementing changes to your IT infrastructure. Every change request goes through a defined lifecycle with risk assessment, implementation planning, rollback planning, and multi-approver sign-off before any work begins.
Changes link to tickets (the incidents that motivated them), assets (the CIs being changed), and CI audit timelines — creating end-to-end traceability from problem to resolution.
Change Types
| Type | Description | Approval Required |
|---|---|---|
| STANDARD | Pre-approved, low-risk, routine changes (e.g., password reset, software patch in maintenance window) | Optional — often pre-approved by policy |
| NORMAL | Planned change with moderate-to-high risk; requires review and approval | Yes — full review cycle |
| EMERGENCY | Urgent change to restore service or prevent imminent outage; expedited approval | Yes — rapid but documented |
Change Request Lifecycle
| Status | Description |
|---|---|
| DRAFT | Created but not yet submitted for review |
| SUBMITTED | Submitted; awaiting review assignment |
| UNDER_REVIEW | Active review by the CAB or designated approvers |
| APPROVED | All required approvers have approved; change may be scheduled |
| REJECTED | Change was denied; requester must revise or abandon |
| SCHEDULED | Approved and scheduled for a specific maintenance window |
| IMPLEMENTING | Implementation is actively underway |
| COMPLETED | Change implemented successfully |
| FAILED | Implementation failed; rollback may have been executed |
| CLOSED | Change fully closed and archived |
Creating a Change Request
- Navigate to Changes → New Change (or click Changes in the sidebar then New Change).
- Fill in the required fields:
| Field | Description |
|---|---|
| Title | Concise description of the change (e.g., "Upgrade core switch firmware to v15.2") |
| Change Type | STANDARD, NORMAL, or EMERGENCY |
| Priority | Critical / High / Medium / Low |
| Risk Level | LOW, MEDIUM, HIGH, or CRITICAL — your assessment of the change risk |
| Impact Level | LOW, MEDIUM, HIGH, or CRITICAL — business impact if the change goes wrong |
| Reason | Business justification — why this change is necessary |
| Description | Full technical description of what will change |
| Implementation Plan | Step-by-step plan for executing the change |
| Rollback Plan | Steps to undo the change if it fails |
| Test Plan | How you will verify success after implementation |
| Scheduled Start / End | Planned maintenance window |
| Required Approvers | Users who must approve this change before it can proceed |
- Click Save as Draft to save without submitting, or Submit to move directly to the review queue.
Approval Workflow
When a change is submitted (SUBMITTED status), designated approvers are notified. Each approver can independently APPROVE, REJECT, or DEFER the change. The change advances to APPROVED only when all required approvers have approved.
Adding Approvers
Approvers are specified in the Required Approvers field when creating the change. Only ADMIN users can move a change to UNDER_REVIEW. Any required approver can approve or reject from the change detail page.
Approval Decisions
| Decision | Effect |
|---|---|
| APPROVED | This approver's step is complete; next approver is notified |
| REJECTED | Change moves to REJECTED status; requester must revise |
| DEFERRED | Approver requests more information; change stays in UNDER_REVIEW |
Linking Tickets & Assets
Connect changes to the incidents that motivated them and the assets that will be affected.
Linked Tickets
On the change detail page, scroll to Linked Tickets and click Add Ticket. Search for the incident ticket by ID or title. Multiple tickets can be linked to a single change — useful when a single change fixes multiple reported issues.
Linked Assets
On the change detail page, scroll to Linked Assets and click Add Asset. Link all CIs that will be affected by the change. When the change reaches IMPLEMENTING or COMPLETED status, a CHANGE_APPLIED event is automatically written to each linked asset's CI audit timeline.
Change Impact Preview
Before approving a change, reviewers can use the Impact Preview (available on the change detail page) to visualize the blast radius.
The impact preview uses the CMDB relationship graph to identify all CIs that depend on the linked assets — showing which business services, applications, and users could be affected if the change causes an outage. This helps the CAB make informed approval decisions.
Implementation
- Once APPROVED, the assigned tech moves the change to SCHEDULED by setting or confirming the scheduled start/end dates.
- When the maintenance window begins, click Begin Implementation — status changes to IMPLEMENTING.
- Execute the implementation plan step by step. Update the change record with progress notes.
- Run the test plan to verify success.
Closure
After implementation:
- If successful: click Mark Completed — status changes to COMPLETED. Add completion notes. Then click Close to archive.
- If failed: click Mark Failed — status changes to FAILED. Document what went wrong and whether the rollback plan was executed. Then close.
CLOSED changes are read-only but remain searchable and visible in the change history.
Change Numbering
Change requests are auto-numbered using a configurable prefix and sequence (e.g., CHG-0001). Configure the numbering scheme in Admin → Settings → Change Numbering. You can set a prefix, the starting number, and the zero-padding width.
Analytics & Export
Navigate to Changes and click the Analytics tab to view:
- Change volume by type, status, and risk level
- Success vs. failure rate
- Average lead time (DRAFT to COMPLETED)
- Changes by requestor and assignee
Click Export to download the change list as CSV or XLSX for reporting to management or auditors.