Change Management

Prerequisites

• Role with changes.view for viewing change records, the change calendar, and governance templates
• Role with changes.manage for creating, submitting, implementing, and completing change records
• Role with changes.approve for CAB approval or rejection of submitted changes
• Role with settings.manage for creating change freeze windows and emergency overrides

Change types

Every change record is classified as one of three types. The type determines the approval workflow and level of documentation required.

Change lifecycle

Every change record follows a structured status workflow. The available transitions depend on the current status.

Status descriptions

Creating a change record

Change records capture the full context of a planned change: what is being changed, why, the risk involved, and how to roll back if something goes wrong.

1. Navigate to Change Management from the sidebar.
2. Click Create Change.
3. Enter a descriptive Title that summarizes the change.
4. Select the Organization where the change will take effect.
5. Choose the Change Type: Standard, Normal, or Emergency.
6. Set the Risk Level based on your assessment (see Risk Assessment below).
7. Fill in the Implementation Plan with step-by-step instructions for carrying out the change.
8. Fill in the Rollback Plan describing how to revert the change if it fails.
9. Fill in the Test Plan describing how to verify the change was successful.
10. Set the Scheduled Start and Scheduled End times for the maintenance window.
11. Toggle CAB Required if the change needs Change Advisory Board approval (enabled by default for Normal and Emergency changes; disabled for Standard changes).
12. Toggle PIR Required if a Post-Implementation Review should be completed after implementation.
13. Click Save. A ticket number is automatically generated (e.g., CHG-001).

Risk assessment

Every change record includes a risk level that reflects the potential impact of the change on the environment. Set the risk level based on these guidelines:

Impact analysis

After creating a change, you can run an Impact Analysis to identify affected hosts and host groups. The analysis traverses the host group dependency graph to find all downstream systems that could be impacted by the change. The result includes a total affected count and may adjust the risk level based on the scope of impact.

CAB approval process

The Change Advisory Board (CAB) reviews Normal and Emergency changes before implementation can begin. The CAB process ensures changes are properly assessed, planned, and authorized.

1. The change author completes the change record in Draft status with all required fields (implementation plan, rollback plan, schedule).
2. The author clicks Submit for Review. The status moves to Submitted.
3. All users with the changes.approve permission in the same account are automatically notified that a change requires review.
4. A CAB member reviews the change details, risk assessment, implementation plan, and rollback plan.
5. The CAB member either Approves or Rejects the change, optionally adding notes explaining the decision.
6. If approved, the change moves to Approved and can proceed to implementation.
7. If rejected, the change moves to Rejected. The rejection notes explain what needs to be addressed. The author can return the change to Draft, make corrections, and resubmit.

Who can approve

Any user whose role includes the changes.approve permission can approve or reject changes. Account Administrators have this permission implicitly. The system records who approved or rejected the change and when the decision was made.

Implementation tracking

Once a change is approved (or scheduled), track the implementation through start and completion.

1. When you are ready to begin the change, click Start Implementation. The status moves to Implementing and the actual start time is recorded.
2. Carry out the change according to the implementation plan.
3. When implementation is complete, click Complete Implementation.
4. If PIR is required, the status moves to Review (pending Post-Implementation Review).
5. If PIR is not required, the status moves directly to Closed and the linked ticket is resolved.

Both the scheduled times (planned) and actual times (recorded at start/complete) are tracked, allowing you to compare planned vs. actual implementation windows.

Source tracking

Change records that were automatically created by other modules (patch deployments, remediation actions, workflows) include a source reference. This allows you to trace the change back to its origin and understand the full context of why the change was initiated.

Post-Implementation Review (PIR)

A PIR captures the outcome of a change after implementation is complete. PIRs are required for Emergency changes and optional for Normal changes. They provide a structured record of what happened and lessons learned.

1. After implementation is marked complete, the change moves to Review status (if PIR is required).
2. Navigate to the change record and click Submit PIR.
3. Select the Outcome from the list below.
4. Enter PIR Notes with details about what went well, what went wrong, and lessons learned.
5. Click Submit. The change moves to Closed and the linked ticket is resolved.

PIR outcomes

Change freeze windows

Change freeze windows block automated changes during sensitive periods such as quarter-end, audit windows, or deployment freezes. When a freeze is active, the patch engine and remediation engine hold all changes.

1. Navigate to Settings > Change Freeze.
2. Click Create Freeze Window.
3. Select the target organization.
4. Set the start and end dates/times (UTC).
5. Select the Scope to control what is blocked.
6. Enter a reason for the freeze.
7. Click Save.

Freeze scopes

Emergency override

If an urgent change is needed during a freeze, users with settings.manage can issue an emergency override. The override requires a written justification, records who approved it and when, and creates a full audit trail. The freeze is deactivated but the override record is preserved.

Governance templates

Governance templates define the approval gates and notice requirements for change records. They enforce a consistent review process across the organization, scaled to the maturity level of your change management practice.

Maturity levels

Gates

Each template defines one or more approval gates. Gates can be marked as required (must be completed before the change can be approved) or optional (informational, tracked but not blocking).

Each gate can be configured with:

• Approver Group — the assignment group responsible for completing this gate
• Notification Group — the group that receives a notification when this gate is reached
• Auto-approve Timer — if set, the gate is automatically approved after the specified number of minutes without action
• Advance Notice — how many minutes before the scheduled start time to send a notification

Notice period enforcement

Templates can enforce a minimum notice period (default: 48 hours). If a change is scheduled to start within the notice period, it cannot be approved unless an override reason is provided. This ensures stakeholders have adequate time to prepare for the change.

Setting a default template

One template per account can be marked as the default. When a new change record is created, the default template is automatically applied. Only one template can be the default at a time — setting a new default clears the previous one.

Change calendar

The Change Calendar provides a unified timeline view of all scheduled activity across your organization. It combines three event types into a single calendar view:

Use the calendar to spot scheduling conflicts between changes and freeze windows, ensure changes are planned within maintenance windows, and coordinate across teams.

Field reference

Change record fields

Permissions reference

Troubleshooting