[object Object]

Change Types

Standard (pre-approved repeatable changes like quarterly patching or daily DNS record updates), Normal (CAB-reviewed changes that touch production but aren’t novel), Emergency (expedited path for outage response or zero-day patching). Define the criteria that put a change into each bucket and don’t let requesters self-classify — automate it via the risk questionnaire below. A common rookie mistake: routing every change as Normal because it feels safe, which floods CAB and turns the meeting into theater.

Risk Assessment

A Workflow Automator-driven questionnaire scores each change. Sample questions: how many CIs are touched, what time of day is the implementation window, is there a documented rollback plan, has this exact change been done before, what is the customer-facing impact if it fails. Each answer carries a weight; the sum classifies the change as Low (auto-approve), Medium (single-approver), or High (CAB). Threshold-based scoring beats arbitrary judgment because it produces reproducible results auditors can defend.

// Create a change with risk fields populated
fetch(`https://${domain}.freshservice.com/api/v2/changes`, {
  method: 'POST',
  headers: { Authorization: auth, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    subject: 'Upgrade payment-service to v2.4',
    requester_id: 12,
    risk: 2,
    change_type: 1,
    status: 1,
    planned_start_date: '2026-05-04T22:00:00Z',
    planned_end_date: '2026-05-04T23:00:00Z',
    custom_fields: { rollback_plan_attached: true, ci_count: 3 }
  })
});

Approval Workflows

Multi-stage approvals: technical reviewer (peer engineer), change manager (process gatekeeper), business stakeholder (impact owner). Configure parallel or sequential approvals depending on risk type. The Workflow Automator handles routing — approval requests fire as email, in-app notification, and Slack/Teams message via the Marketplace integration. Approval timeouts auto-escalate after 24 hours so a vacationing approver doesn’t block the change indefinitely.

CAB

Weekly meeting for Normal changes that scored above the auto-approve threshold. CAB members: change manager (chair), key technical leads from affected teams, business owner for customer-facing systems, security representative for changes that touch authentication or PII. Outcome per change: approved, deferred (revise and resubmit), rejected (will not implement). Don’t invite everyone — large CABs become rubber-stamps. The right size is 5-7 people who can read the change request before the meeting and ask substantive questions.

Post-Change Review

Post-Implementation Review (PIR) for every change, not just unsuccessful ones. The PIR captures actual start/end times, deviation from plan, issues encountered, and lessons. Track success rate as a leading indicator — below 90% triggers process tightening (more rigorous risk scoring, mandatory rollback plans, more peer review). Above 99% suggests the process is too tight; consider promoting more change types to Standard.

Common Failure Modes

Three. First, Emergency changes used as a bypass — anything urgent gets called Emergency to avoid CAB; track Emergency change ratio per requester and coach the chronic abusers. Second, rollback plans that exist as a checkbox but no actual procedure attached; require an attached document or a link, and audit a sample monthly. Third, no integration between the change record and the deploy automation — engineers check a box that says “deployed” without the deployment actually happening; integrate with your CI/CD so the change record updates from the deploy event.

Implementation Sequence

Month 1: define the three change types and the risk questionnaire. Month 2: configure approval workflows and pilot with one team. Month 3: launch CAB with a small membership. Month 4: roll out to all teams. Month 5: introduce success-rate tracking and start tightening or loosening based on data. Don’t try to launch full change management in 30 days — the cultural change takes longer than the configuration.

What to do this week

Pull the last quarter’s change success rate by team and by type. Outliers (a team with 60% success while the org average is 92%) point to a coaching opportunity, not a process problem.

[object Object]
Share